Есть 3 кассеты для Специалиста...

[Bolt]

Да, хорошо. Если что найду потом отдельно выложу.

---------- Post added at 17:32 ---------- Previous post was at 17:25 ----------

А я только своими пользуюсь.
...
Некоторые работают со звукокартой напрямую...

"Со звуковой картой напрямую" не все кассеты могут выдержать... Лучше загнать в файл, а потом уже его обрабатывать хоть десятью способами.

[HardWareMan]

"Со звуковой картой напрямую" не все кассеты могут выдержать... Лучше загнать в файл, а потом уже его обрабатывать хоть десятью способами.

Согласен. Несколько записей я буквально руками восстановил в саунд форже (правил вэйвформу руками).

[DDp]

выложите пожалуйста записи с кассет, очень хочется посмотреть какие искажения ещё бывают и попробовать это обработать.

Напр. http://zx.pk.ru/showthread.php?t=20292
unknown_8.ogg - хорошие искажения . Половина файлов текстовые.

[Bolt]

Отлично!
Суть искажений везде кажется одна и та же, что у меня, что в этих .ogg, причём по-моему ogg это даже как-то подчёркивает.

Рассматриваю осциллограммы и сочиняю фильтры

[HardWareMan]

Да че там думать то? Нужен обычный компаратор с гистерезисом. Это работает в железе, проверено десятилетиями. Его математическая модель не будет слишком сложной.

PS OGG номер 8. Тексты Микрона/Практика. Ах, кружок. Вроде как окунулся в детство... Запомни, у текста другая контрольная сумма. Вот тебе легенда в помощь:

1. Блок кодов:
0E6H,<ADR_BEG>,<ADR_END>,<BIN_CODE><CHECK_SUM>
При загрузке по сбросу имеет свойство автозапуска. Раккорд - 512 байт 00H.

2. Блок кодов с именем (монитор):
0E6H,0D9H,0D9H,0D9H,<ASCII_NAME>,00H
0E6H,<ADR_BEG>,<ADR_END>,<BIN_CODE>,<CHECK_SUM>
Раккорд перед именем - 512 байт 00Н, между именем и блоком кодов - 256 байт 00Н.

3. Бейсик "Практик":
0E6H,0D4H,0D4H,<ASCII_NAME>,00H
0E6H,0D3H,0D3H,0D3H,<BIN_CODE>,00H,00H,00H,<CHECK_ SUM>
Да, при линейной загрузке интерпретатор ждет трёх нулей подряд (первый ноль - конец строки, второй и третий - номер строки #0, что нонсенс). Раккорд - 256 байт ААН и 256 байт 00Н. Между именем и листингом - 256 байт 00Н.

4. Редактор текстов "Практик" (и "Микрон" тоже, ЕМНИП):
0E6H,0E6H,0E6H,0E6H,0E6H,<ASCII_NAME>,00H
0E6H,<BIN_CODE>,0FFH,<CHECK_SUM>
Текст грузится от начала (задано редактором, обычно 1200H) и до байта FFh (маркер конца текста в памяти). Раккорд - 128 байт ААН, 128 байт 00Н, 128 байт ААН, 128 байт 00Н. Между именем и текстом - 256 байт 00Н.

Легенда:
<ADR_BEG>,<ADR_END>,<CHECK_SUM> - 2 байта, младший первый
<ASCII_NAME>, <BIN_CODE> - N байт массив
<CHECK_SUM> накрывает только <BIN_CODE>, причем у ТХТ она своя (тупое прибавление к слову байта без учета переноса, от 0).

[Titus]

Да че там думать то? Нужен обычный компаратор с гистерезисом. Это работает в железе, проверено десятилетиями. Его математическая модель не будет слишком сложной.

Но и годится только для относительно годных записей.

Я в свое время, когда собирался сделать читалку спектрумовских кассет, тоже сначала хотел сделать по-простому. В итоге понял, что мои старые и заезженные кассеты так не считать, и пришлось придумывать более сложные математические модели типа вейвлет-анализа специфического. Как итог - теперь читалка в автоматическом режиме кушает почти все, что не читают никакие другие читалки.

[Advertiser]

[Bolt]

Но и годится только для относительно годных записей.

Вот-вот. На картинке пример из этого unknown_8.ogg. Некоторые волны только слегка цепляют нулевой уровень, а на моих кассетах иногда вообще не пересекают. Компаратор скажет "ой" и пропустит как минимум один бит.

Я в свое время, когда собирался сделать читалку спектрумовских кассет, тоже сначала хотел сделать по-простому. В итоге понял, что мои старые и заезженные кассеты так не считать, и пришлось придумывать более сложные математические модели типа вейвлет-анализа специфического. Как итог - теперь читалка в автоматическом режиме кушает почти все, что не читают никакие другие читалки.

Не знаю, вейвлет у меня или нет, но получил достаточно чистый промежуточный результат, завтра из него буду байты и файлы вытаскивать, а на сегодня хватит думать.

[Bolt]

Вот тебе легенда в помощь:

Не уверен, декодировал на бумажке из промежуточных данных, но по-моему в unknown_8.ogg файлы редактора текстов "Практик".

Ой, это в сообщении и написано

PS OGG номер 8. Тексты Микрона/Практика.

Раз не могу уже даже внимательно сообщение прочитать - пора на сегодня завязывать с программированием

[HardWareMan]

Вот-вот. На картинке пример из этого unknown_8.ogg. Некоторые волны только слегка цепляют нулевой уровень, а на моих кассетах иногда вообще не пересекают. Компаратор скажет "ой" и пропустит как минимум один бит.

Вы видимо никогда не использовали аппаратный компаратор с гистерезисом. Он измеряет не относительно 0 а относительно текущего уровня, в который вносится фидбэк с выхода. Вот глубина гистрезеиса согласен, величина подстраиваемая должна быть, я себе прямо переменник и ставил. И в 90х считывал все, даже стереозапись с плохим азимутом на моноголовке (примерно то же самое, что и джоинт стерео МР3 для ваших записей).

[Bolt]

Вы видимо никогда не использовали аппаратный компаратор с гистерезисом.

Использовал. Но это не наш метод

О полученном вчера полуфабрикате.
Во вложении файл, в котором записаны... полубиты, что ли.
0 - повтор полубита
1 - инверсия полубита
2 - нет сигнала

Примеры:
0000000000000 - невозможно (но может и встречается, не проверял)
0101010101010 - серия байтов 55 или AA
1111111111111 - серия байтов 00 или FF
2222222222222 - нет сигнала

"Дырка" в сигнале:
0101111101011122220111010111010111110101

Более сложный пример, ракорд и синхробайт.
Биты, полубиты, содержимое файла log_tris:

0 0 0 0 0 0 0 0  0 0 0 0 0 0 0 0  1 1 1 0 0 1 1 0
0101010101010101 0101010101010101 1010100101101001
1111111111111111 1111111111111111 0111110111011101

Ну и совсем сложный пример, на первый взгляд вроде всё правильно, но в сигнале какой-то дефект:
010101111111110101010110110101111101

Синхробайты уже вылавливаются, тексты тоже частично читаются. Буду думать дальше. От помощи в обдумывании не откажусь