Вид для печати
сабж, в общем
например, такой плеер
ld hl,<звук>qplay LD a,(hl) ;7
ld c,0 (конец звука, выровненный по 256)
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,<звук>qplay LD a,(hl) ;7
ld c,<High для конца звука>
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+ кгц играет достаточно приемлимо, правда память кушает...
На звуке отражается все.Цитата:
Сообщение от Vitamin
Кроме ряда высокочастотных гармоник, естественных для однобитного прямоугольного сигнала, мы еще и получим дополнительную паразитную гармонику частотой ~1/8 частоты дискретизации, плюс ее субгармоники. Оно вам надо?
ну вы и мозги... :)
Я заметил, что во многих плеерах придумывают разнообразные способы опоределения окончания сампла. Хотел предложить немного альтернативный вариант. Все "0" в сампле меняем на "1", в конце добавляем "0" или десяток нулей, если хотим прыгать через байт(ы). Таким образом сампл можно сделать длиной на вообще всю доступную память. Так было реализовано в моём музыкальном редакторе MASON, где получалась частота на SounDrive 12000 герц с 16-тью громкостями на каждом канале.
ld hl,<звук>loo1ld a,(hl)loo2
or a
jr nz,loo2
out (port),a
inc hl
jmp loo1
ВЧ гармоники будут находиться далеко за пределами области звуковоспроизведения. Другое дело производные частоты, полученные в результате интерференции-сложений-вычитаний. Но на них можно в принципе забить. Потому как если смешать 1 кг варенья (звук без субгармоник) и 1 кг дерьма (1 битный звук), получим 2 кг дерьма...Цитата:
Сообщение от Titus
Да. Это если хранить БАЙТЫ порта. Я предпочитаю хранить биты -- как-никак экономия в 8 раз.)Цитата:
Сообщение от Robus
P.S>: offtopic: Robus, :v2_frown: :v2_cry: ну загляните в тему про саботажников в играх... молю...
Это на случай, елси AY not found. Если found, то зачем, в самом деле, извращаться. Я и не собирался...Цитата:
Сообщение от Vitamin
Это неверное сравнение :v2_cool:Цитата:
Сообщение от Vitamin
Есть звук, а есть помехи и искажения. Чем больше искажений тем хуже звук. Зависимость почти линейная :v2_wink2:
Кроме того основные гармоники в данном случае будут на частоте 5КГц/10Кгц (при частоте семплирования 80КГц), что на слух весьма противно :v2_wacko:
2Titus: Частота будет 44, я уже пересчитал новый вариант.
Но вы меня обнадеживаете. Сегодня напишу небольшой WAV-конвертор (цифровать-то все одно на IBM придется :( ) и проверю...
Ключевые слова -- широтно-импульсная модуляция, ADPCM.Цитата:
Сообщение от TomCaT
Расжёвывать из букваря некогда. Читай CODE.ZX (архивы).
вы имеете в виду, что нужно этот формат паковки сюда применить? или что? А разговоры про букварь -- вообще зря. Это просто отбивает вообще желание учиться.
что-то нифига не работает этот плеер. По расчетам должно полсекунды длиться и хоть что-то звучать. На самом деле клацает и выходит... :(
ага, в концу jr nz, ...
вот, архив-пример. Там плеер в 30 байт и сервисная программка на Delphi для перевода wav файлов в формат плеера. Для хранения и проигрывания многих файлов плеер, конечно, надо чуть корректировать --выход из цикла там при достижении конца ОЗУ...
А занимает секунда около полутора дорожек. Итоого дискета -- 100 секунд :)
Для той задачи, что я хотел сделать, звук занимает одну дорожку. В ADPCM, конечно, меньше, но при распаковке упадет частота воспроизведения. Или для однобитного звука это менее важно?.. Какая все-таки максимальная частота при разумной экономии хранения воспроизводимых бит (т.е. не по биту в одном байте)?
Где?Цитата:
Сообщение от fk0
Вот именно. Мне почему-то даже и выяснять не хотелось... :)
который воспроизводит (только воспроизводит, писать естественно на такой скорости не возможно) на частоте около 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 это вообще ужас, как они работают с этими командами...
Эй, ты не праф ((((-;Цитата:
Сообщение от Vitamin
Ты просто не слышал последние версии ((((((-;
Спасибо, интересный способ. Только для коротких звуков в интре такое как-то не хочется вытворять. Разве что сжать перед созданием файла игры...
Насчет переходов... Почему намучаюсь? Имеете в виду, что длительность у них плавающая на разных машинах? Ну, это уж, извините, хардовые проблемы. Почему они должны меня занимать (точно так же, как и вылет бордюрного рисунка неизвестно куда на плохо склепанных клонах)? Это не должно лежать на совести программиста, когда есть документация с указанием тактовой длительности. Конечно, честь с халвой, если удается обойти все эти различия моделей. Но усложнять или удлинять код ради этого лично я не хочу. Мое, субъективное мнение.
вот только % скорпионов и им подобных компов достаточно велик, другой вопрос включают ли их, а не юзают эмулятор...Цитата:
Сообщение от TomCaT
Тогда перед загрузкой плеера, может, определять тип машины?.. И грузить тогда нужную версию плеера (если качество и в самом деле намного упадет!..).
У тебя сэмплы то такие есть? :biggrin:Цитата:
Сообщение от GriV
Другими словами, не занимайся фигнёй - поставь отметку в 22 - 44(48) khz и успокойся.
ртфм ШИМ, adpcmЦитата:
Сообщение от key-jee
Выше уже ответили ((((-;Цитата:
Сообщение от key-jee
Но тем не менее, сэмплы есть я их из стандартных 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.