Просмотр полной версии : максимальная частота оцифровки при воспроизведении БЕЗ AY
сабж, в общем
например, такой плеер
ld hl,<звук>
ld c,0 (конец звука, выровненный по 256)
qplay LD a,(hl) ;7
ld b,8 ;7
rrca ;4
out (fe),a ;12
nop ;
nop ;8
djnz $-5 ;13/8
inc hl ;7
ld a,h ;4
cp c ;4
jr c,qplay ;12/7
пересчет тактов дает:
37*8-5+14+15+12=332 -- т.е. столько тактов на 8 бит вывода
3.5*1000/332*8=84.33Khz -- так? или напутал что?
Может и так (хотя плеер можно написать и более "качественно"), но встречный вопрос: что ты им проиграешь? откуда столько памяти возьмёшь?
Да мне короткий звук эффект в заставке, и 30к хватит с головой...
Да, а намного качественнее? меня все-таки интересует не этот быстро склепанный пример, а максимум?
Фсе попутал :v2_wink2:
Нет даже компенсации тактов при перехода с байта на байт :v2_jawdr:
Ну ламер, так и говорите, не обижусь. У меня вообще от потактовых расчетов зубы начинают болеть... ;) неужели это смертельно скажется на результате?
получается пауза в полтора бита после каждого байта, что ли?
ну тогда djnz переделываю на прыжок в 43-тактовую задержку перед rrca. а после ld b,8 -- обход этой задержки прямо на rrca. Итого 43318Hz?
ld hl,<звук>
ld c,<High для конца звука>
qplay LD a,(hl) ;7
ld b,1dh ;7
jr $+9 ;7
djnz $+2 ;13+
djnz $+2 ;+13+
djnz $+2 ;+13+
nop ;+4=43
rrca ;4
out (fe),a ;12
nop ;
nop ;8
djnz $-12 ;13/8
inc hl ;7
ld a,h ;4
cp c ;4
jr c,qplay ;12/7
Хехе... Компенсация переходов между байтами... Да фихня это! Даже переход между страницами на звуке практически не отражается, а тут еще и звук однобитный, качеством особо не отличается (даже на 80кгц). У GriV'а есть плеер такого звука со сжатием, на 100+ кгц играет достаточно приемлимо, правда память кушает...
Хехе... Компенсация переходов между байтами... Да фихня это! Даже переход между страницами на звуке практически не отражается, а тут еще и звук однобитный, качеством особо не отличается (даже на 80кгц). У GriV'а есть плеер такого звука со сжатием, на 100+ кгц играет достаточно приемлимо, правда память кушает...
На звуке отражается все.
Кроме ряда высокочастотных гармоник, естественных для однобитного прямоугольного сигнала, мы еще и получим дополнительную паразитную гармонику частотой ~1/8 частоты дискретизации, плюс ее субгармоники. Оно вам надо?
Darkman007
21.09.2006, 18:03
ну вы и мозги... :)
Я заметил, что во многих плеерах придумывают разнообразные способы опоределения окончания сампла. Хотел предложить немного альтернативный вариант. Все "0" в сампле меняем на "1", в конце добавляем "0" или десяток нулей, если хотим прыгать через байт(ы). Таким образом сампл можно сделать длиной на вообще всю доступную память. Так было реализовано в моём музыкальном редакторе MASON, где получалась частота на SounDrive 12000 герц с 16-тью громкостями на каждом канале.
ld hl,<звук>
loo1
ld a,(hl)
or a
jr nz,loo2
out (port),a
inc hl
jmp loo1
loo2
На звуке отражается все.
Кроме ряда высокочастотных гармоник, естественных для однобитного прямоугольного сигнала, мы еще и получим дополнительную паразитную гармонику частотой ~1/8 частоты дискретизации, плюс ее субгармоники. Оно вам надо?
ВЧ гармоники будут находиться далеко за пределами области звуковоспроизведения. Другое дело производные частоты, полученные в результате интерференции-сложений-вычитаний. Но на них можно в принципе забить. Потому как если смешать 1 кг варенья (звук без субгармоник) и 1 кг дерьма (1 битный звук), получим 2 кг дерьма...
Я заметил, что во многих плеерах придумывают разнообразные способы опоределения окончания сампла. Хотел предложить немного альтернативный вариант. Все "0" в сампле меняем на "1", в конце добавляем "0" или десяток нулей, если хотим прыгать через байт(ы). Таким образом сампл можно сделать длиной на вообще всю доступную память. Так было реализовано в моём музыкальном редакторе MASON, где получалась частота на SounDrive 12000 герц с 16-тью громкостями на каждом канале.
Да. Это если хранить БАЙТЫ порта. Я предпочитаю хранить биты -- как-никак экономия в 8 раз.)
P.S>: offtopic: Robus, :v2_frown: :v2_cry: ну загляните в тему про саботажников в играх... молю...
Потому как если смешать 1 кг варенья (звук без субгармоник) и 1 кг дерьма (1 битный звук), получим 2 кг дерьма...
Это на случай, елси AY not found. Если found, то зачем, в самом деле, извращаться. Я и не собирался...
ВЧ гармоники будут находиться далеко за пределами области звуковоспроизведения. Другое дело производные частоты, полученные в результате интерференции-сложений-вычитаний. Но на них можно в принципе забить. Потому как если смешать 1 кг варенья (звук без субгармоник) и 1 кг дерьма (1 битный звук), получим 2 кг дерьма...
Это неверное сравнение :v2_cool:
Есть звук, а есть помехи и искажения. Чем больше искажений тем хуже звук. Зависимость почти линейная :v2_wink2:
Кроме того основные гармоники в данном случае будут на частоте 5КГц/10Кгц (при частоте семплирования 80КГц), что на слух весьма противно :v2_wacko:
2Titus: Частота будет 44, я уже пересчитал новый вариант.
Но вы меня обнадеживаете. Сегодня напишу небольшой WAV-конвертор (цифровать-то все одно на IBM придется :( ) и проверю...
сабж, в общем
пересчет тактов дает:
37*8-5+14+15+12=332 -- т.е. столько тактов на 8 бит вывода
3.5*1000/332*8=84.33Khz -- так? или напутал что?
Ключевые слова -- широтно-импульсная модуляция, ADPCM.
Расжёвывать из букваря некогда. Читай CODE.ZX (архивы).
вы имеете в виду, что нужно этот формат паковки сюда применить? или что? А разговоры про букварь -- вообще зря. Это просто отбивает вообще желание учиться.
что-то нифига не работает этот плеер. По расчетам должно полсекунды длиться и хоть что-то звучать. На самом деле клацает и выходит... :(
ага, в концу jr nz, ...
вот, архив-пример. Там плеер в 30 байт и сервисная программка на Delphi для перевода wav файлов в формат плеера. Для хранения и проигрывания многих файлов плеер, конечно, надо чуть корректировать --выход из цикла там при достижении конца ОЗУ...
А занимает секунда около полутора дорожек. Итоого дискета -- 100 секунд :)
Для той задачи, что я хотел сделать, звук занимает одну дорожку. В ADPCM, конечно, меньше, но при распаковке упадет частота воспроизведения. Или для однобитного звука это менее важно?.. Какая все-таки максимальная частота при разумной экономии хранения воспроизводимых бит (т.е. не по биту в одном байте)?
captain cobalt
22.09.2006, 20:25
Читай CODE.ZX (архивы). Где?
Вот именно. Мне почему-то даже и выяснять не хотелось... :)
который воспроизводит (только воспроизводит, писать естественно на такой скорости не возможно) на частоте около 280 кГц.
Тело проигрывателя получается типа:
Out (с),X
Out (с),X
Out (с),X
Out (с),X
..
и так 12 раз.
- это тело герерируется рабочей программы, алгоритм там что называется рехнуться можно, однако работает.
Out (с),X - это команда либо Out (c),c (т.е. вывод в порт 254 значения 254 - логическая единица), либо out (c),0 (часто встречается в виде out (c),(hl) или out (c),f) - соответственно для логического нуля.
Память расходуется просто жутко - посчитается сами - около 12 тактов на одно прогрывение (так как есть управляющие команды кроме выводящих), итого на 256 кб памяти около 8-10 секунд, для метровых машин параметр конечно повыше будет (((-; одним словом мультимедия.
Если надо могу кодер дать и декодер (((((((-;
Ага, чуть не забыл.
Тут фишка есть - дело в том, что в связи с такой скоростью пришлось оптимизировать уже не сам код (который уже некуда оптимизировать - и так одни АУТы), а данные которые на входе к проигрывателю идут. В результате, на 1 байт я использую только 6 бит (формат типа ADPCM), причём это теоретический предел для моей концигурации (т.е. тело декодера настолько здоровое, что еле-еле помещается в основную память). Я просчитывал для машин с теневым ОЗУ можно задействовать ещё бит, но честно говоря возиться с теневым ОЗУ было совсем не интересно, да и прирост не столь качественный чтобы этим заниматься.
И ещё, огромный (и наверное единственный) недостаток оцифровок с speaker'а заключается в том, что в способе модуляции звука отсутствует возможность управлять низкочастотной составляющей. Сейчас я думаю как бы адаптировать систему для того, чтобы можно было расколбасить басы - например выводить низкочастотную составляющую прямо на AYк - как известно эту часть AYк хорошо воспроизводит.
И ещё, тут я посмотрел в коде используются такие команды как "jr nz" "djnz" и прочее. Так вот, избегайте их в проигрывателях, потому что намучаетесь их компенсировать. Я реально сталкивался с тем, что приходилось изворачиваться до одури и не получалось сделать "ровный" звук. Используйте "JP NZ", "DEC B JP NZ" соответственно с этими командами, в байтах оно будет конечно больше, зато в тактах всё будет чётко. Для машин с М1 это вообще ужас, как они работают с этими командами...
Потому как если смешать 1 кг варенья (звук без субгармоник) и 1 кг дерьма (1 битный звук), получим 2 кг дерьма...
Эй, ты не праф ((((-;
Ты просто не слышал последние версии ((((((-;
Спасибо, интересный способ. Только для коротких звуков в интре такое как-то не хочется вытворять. Разве что сжать перед созданием файла игры...
Насчет переходов... Почему намучаюсь? Имеете в виду, что длительность у них плавающая на разных машинах? Ну, это уж, извините, хардовые проблемы. Почему они должны меня занимать (точно так же, как и вылет бордюрного рисунка неизвестно куда на плохо склепанных клонах)? Это не должно лежать на совести программиста, когда есть документация с указанием тактовой длительности. Конечно, честь с халвой, если удается обойти все эти различия моделей. Но усложнять или удлинять код ради этого лично я не хочу. Мое, субъективное мнение.
Мое, субъективное мнение.вот только % скорпионов и им подобных компов достаточно велик, другой вопрос включают ли их, а не юзают эмулятор...
Тогда перед загрузкой плеера, может, определять тип машины?.. И грузить тогда нужную версию плеера (если качество и в самом деле намного упадет!..).
Я делал кодек
который воспроизводит (только воспроизводит, писать естественно на такой скорости не возможно) на частоте около 280 кГц.
У тебя сэмплы то такие есть? :biggrin:
Другими словами, не занимайся фигнёй - поставь отметку в 22 - 44(48) khz и успокойся.
У тебя сэмплы то такие есть?ртфм ШИМ, adpcm
У тебя сэмплы то такие есть?
Другими словами, не занимайся фигнёй - поставь отметку в 22 - 44(48) khz и успокойся.
Выше уже ответили ((((-;
Но тем не менее, сэмплы есть я их из стандартных 44кгц делал, фишка в том, что 44кгц имеет глубину 16 бит, а у меня только 1, потому и приходиться выкручивать руки для обеспечения качества...
Кстати, для стандартного спекка (3,5 мгц) указанная величина - 280 кгц является в общем то теоретическим пределом и быстрей выводить никак не получится. Так что этот метод я бы назвал абсолютным (((((-; с этой точки зрения полезно его знать (((((-;
2GriV: тогда тема закрыта? :) По сути, максимальная скорость достигается элементарно: Подряд пишутся команды записи в порты вперемежку с записью в видеобуфер :v2_lol: Но память :v2_cry: И внешняя тоже -- даже если упаковать, сколько секторов, к примеру, займет секунда цифорвки вашим методом?
наверное меня неправильно поняли - такой метод - по два байта на 1 вывод в порт (out (c),X) я не использовал (т.е. вместо данных готовый исполняемый код), именно имеются медиаданные, просто представленные хитрым способом, чтобы достичь максимальной производительности. За 1 секунду расходутся около 45 кбайт. На 256 кб моего скорпиона получалось (2 страница на декодер, 224 кб свободно, итого около 5 секунд )))): ).
Легко подсчитать что если вмеcто медиаданных записывать готовый код, то получится (хехе), на 256 кб скорпиона менее 1 секунды (около 80 мс), на такие жертвы ради скорости я идти не готов :-D
мгм. 5 секунд -- это "пять" :)
Да нет, я все понял, думаю... Это действитеьно максимальная частота, причем с некоторым хитрым уменьшением памятепожирания (упаковывается, видимо, это все оч. хорошо, OUT-то везде одинаковым байтом...). Но тот цифровой эффект, что я хочу в интре, не должен занимать места столько, как все остальные данные игры ;) Так что за счет качества выиграю в пространстве. (у моего плеера 1 сек в несжатом виде -- ~6Kb, при 43KHz. По-моему, неплохо, хотя и не максимум... ;) )/ Но это так, оффтоп, ведь вопрос был про максимальную частоту.
в которой я как раз делал более менее частоту (около 190 кгц) и при этом использование памяти было 100% (в отличие от абсолютного метода), посмотри конкретно http://zx.pk.ru/showthread.php?t=386, фишка же в том, что есть алгоритмы без оптимизации звучания в размер (т.е. которые можно заставить сжать сильней, за счёт качества), так и те, которые никак нельзя оптимизировать. По ссылке как раз представлены первые. Например, речь сжимается идеально, хотя остаётся характерный ШИМ-свист.
Есть. Алгоритмы есть. А писалки звука к этим алгоритмам есть удобные? А собрать это все воедино, чтоб был удобный пакет -- вот тогда было бы круто... И если уже есть такая вещь, я, конечно, заброшу свои попытки изобрести велосипед. :)
(кстати, в Unreal сбрасывалось, но это я скорп не выбрал... щас попробую скорпом. Но судя по отзывам -- вещь!)
-- позже --
Попробовал. Улет (:v2_sediment: , осадок в смысле. Это я такой смайлик бы просто хотел, название вот уже придумал :) ). Так, это если вся дискета забита данными оцифровки? А можно хоть довести до 40кбайт/сек (сжатые данные на дискете), или бесполезно и пытаться?
З.Ы.: да, а еще, конечно, надо вылечиться от скорпозависимости параллельно (но это, я так понял, уже пофиксено). Т.е. если удастся все-таки 40-42 кбайт/сек довести в архивированном блоке на дискетке... и чтобы даже ZX 48к мог бы попытаться что-то "сказать", было бы СУПЕР. Я сниамю перед вами шляпу, а если удастся сделать вышеперечисленное, то это будет... "победа невозможного" (есть такая фраза в литературе, кажется, автор Электроника ее использовал...)
а всё остальное из высказанного я не понял ((((-;
Если Unreal сбрасывается нафик его (((-; я и на реале и на эмулях пускал это дело работает. Сбрасывается скорей всего из-за того, что первые версии работали под только скорпион, последняя вроде универсальная - под любой типа машины, поддерживает до 1 мб ОЗУ (конечно же его портит, грузит туда медию).
Мысль всё-таки объясни насчёт 40-42кб, в смысле чтобы можно было загрузить в основную памяти с диска проиграть и двигать дальше?
Извините, правил предыдущую мессагу. Сейчас должно быть вразумительнее :(
(((-; а до 40 кб в сек можно довести, причём де факто нет разницы выводить на AY или на бипку - даже на бипку лучше, потому что можно intAY звук выводить (((-; я тут как-то даже предлагал сделать звуковой редактор, который бы мог выводить звук и на AY и на бипку одновременно (на AY как цифровой так и FM), но это оффтоп.
Ещё раз, в жертву качества можно получить любой конечный размер, чем меньше размер, тем ниже качество и больше свист (сказочку то прослушал? "Послушай, Вань, меня..") ;-))))) там целую минуту на 256 кб засунул, вот и посчитай - получается около 3 кб на секунду.
В общем, али так, али эдак. И без DMA для какого-то внеш. носителя побольше толку выходит мало. Я, в общем, так и написал, что невозможно и волков накормить, и овец сохранить... Все равно, спасибо за шедевррр.
так это связь размера "сжатых" данных, их качества и исходного материала. В итоге получается, чтобы получить более-менее схожее с оригиналом качество, надо сделать чтобы сжатый файл был размером... с оригинал или даже больше!!!
Т.о. использование CD как источник хранимых данных не теряет своей актуальности ((((((((-;
А потому продолжение разговора надо переносить в "Железо". Сделают аппаратное обеспечение работы с огромной памятью без затрат времени ЦП (с оперативной ли, с внешней -- это, вообще-то, пополам ;) ) -- тогда и рекорд частоты можно бить, причем не одной секундой игры ;) Т.е. рекорд, конечно, и сейчас установлен. Но это все равно, что радиевые часы или ГЭС называть вечным двигателем. Он вечный, конечно, ... для нас, хиляков, которые и века протянуть не могут :)
го для справки - похожий тип подуляции (ШИМ) используется в SACD - не очень удавшийся приемник CD-Audio. У него несущая составляет кажется 10 МГц (точнее не помню), и позиционируется сие как DVD-Audio.
вы имеете в виду, что нужно этот формат паковки сюда применить? или что?
Формат здесь ни при чём. Речь об алгоритмах. ДВУХ. СЖАТИЯ И ВЫВОДА.
Одно к другому совершенно ортогонально.
В том что вы пытаетесь сделать нет никакого смысла. Давно показано (лет так 7 тому назад, Иваном Макарченко в упомянутой CODE.ZX) -- ШИМ на бипер реализуем, просто и эффективен, а главное, звучит более-менее пристойно.
Вопрос в объёме памяти. Поэтому возможно применение алгоритмов сжатия звука, вроде ADPCM. Они работают лучше, чем Hrust. И вовсе не факт, что разжатие и проигрывание должно производиться одновременно.
Частоту модуляции, понятное дело, стоит выбрать выше чем воспринимаемая человеческим ухом. Много выше. Но чтоб при этом не задирать сильно частоту дискретизации (опять совершенно разные и непересекающиеся понятия) стоит подумать о хранении звука с относительно низкой частотой дискретизации (6-8кГц) и передискретизации перед выводом на частоту модуляции. Без передискретизации вы услышите этот противный писк в 8кГц (почему,
думаете, все MOD-проигрыватели, кроме GS так скрипят?)
Метод передискретизации пойдёт простейший -- вроде "zero stuffing"
плюс фильтр нижних частот (тривиальный, загляните в application notes
раздаваемые Texas Instruments для MSP430 в области записи/воспроизведения звука). А может и просто линейная интерполяция.
При записи звука совершенно точно не помешает "компрессия" динамического диапазона записи и качественная передискретизация
с частотой в которой оно будет сжиматься и храниться.
При использовании ADPCM для речи результат может быть достигнут
при 2-разрядом ADPCM и 7КГц частоте дискретизации. Разборчивый результат, но не очень хороший. Для ADPCM вообще снижение частоты
дискретизации при одновременном снижении разрядности сильно
всё портит -- алгоритм или не успевает быстрыми изменениями сигнала
или начинает шуметь. Тут вобщем есть широкое поле для экспериментов... Возможно подойдут адаптивные алгоритмы, которые при
увеличении ошибки кодирования увеличивают, соответственно или частоту дискретизации или разрядность.
НО ГОТОВЫХ РЕШЕНИЙ -- НЕ ЖДИТЕ (они, как минимум, стоят времени).
А разговоры про букварь -- вообще зря. Это просто отбивает вообще желание учиться.
Ваши трудности.
Если по-существу -- вам с этим вопросом лучше в group:fido7.ru.embedded. Там, думаю, найдутся люди желающие ответить на ваши вопросы, что-то подсказать. А тратить время на форум (написал и выкинул) даже у меня нет желания.
Где?
Я может сильно удивлю, но существует (вроде ещё?) такая FTN-сеть -- ZXNET.
Где? Сложно сказать. Вроде, Славка Калинин в состав своих дисков с Virtual TR-DOS (или просто на дисках Virtual TR-DOS) оно было. Ибо точно
помню, мне показывали как с этого диска можно голдедом все письма
тех лет читать.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot