Форум РадиоКот

Здравствуйте.

Возникла задача сложить два звуковых файла между собой на микроконтроллере. Само собой напрашивается решение записать файлы в формате PCM, ну и складывать побайтно, результат воспроизводить через шим 16 - разрядный. Провёл эксперимент, в Adobe Audition 1.0 сгенерировал две частоты, сохранил их в .txt формате (тот же PCM, только блокнотом открывается) потом свёл и результат тоже записал. Теперь смотрю и не могу понять алгоритма сведения, это совсем не похоже на математическое сложение.

Будьте добры, расскажите, как складывать звуки.

Создание устройства планируется на Меге 8, разогнаной до 16МГц внешним кварцем.

По-моему проще было бы сделать с помощью ISD4004

Kashey писал(а):Здравствуйте.

Возникла задача сложить два звуковых файла между собой

Будьте добры, расскажите, как складывать звуки.

А что конвертером на компьютере не пробовал?
Там же вроде любые звуковые файлы можно клеить.

Насколько я разбираюсь в музыке, несмотря на наступившего на ухо медведя , у проф. музыкантов термин "сведение" означает нечто более серьёзное, чем простое сложение. Так что уместнее было бы просто "сложение звуков ". Не представляю, как Блокнотом можно работать со звуковыми файлами, а вот 2 wav файла слить вместе когда мне понадобилось -- простая прога получилась. Стандартных, увы, не знаю, Что-то типа Soundforge, память подсказывает. Но она вроде за денежку.
Оказалось всё намного проще. В стандартной Винде "Стандартные -- Развлечения -- Звукозапись" можно наложить 2 звукрвых файла. Ну а там ещё проще : из суммарного wav файла отрезать преамбулу и данные скопировать в прошивку АВР, преобразовав байты в их HEX представление.
Рекомендую посмотреть формат WAV хотя бы в Вики.

Сохранять надо не в TXT, а в RAW, и открывать не блокнотом, а хекс-редактором. Блокнот вам покажет символы ASCII соответствующие данному байту.
Сведение, это - как правильно заметили, совсем не сложение.
А понять Вы не можете, так как, для сложения, надо увеличивать разрядность. Т.е. складывая два 16-разрядных байта, результирующий должен быть уже 17-разрядным, для сложения четырёх - 18 разрядный, и т.д.
Ну, а структура WAV, это - вообще отдельная "песня".

Разряд можно и не увеличивать звук то такой разрядности все равно не будет. Поделить на целое можно результат либо предварительно делить перед сложением.
На два проще всего делить с помощью сдвига.

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

vitalik_1984 писал(а):Разряд можно и не увеличивать звук то такой разрядности все равно не будет.

В 16-бит WAV звук хранится в знаковом представлении. 0x7FFF+0x7FFF (два самых громких звука в положительной полуволне) при арифметическом сложении дадут 0xFFFE, а это почти ноль в отрицательной полуволне. Возникает т.н. "цифровой клиппинг", когда самые громкие сигналы покрываются громким треском.

Kashey писал(а): Провёл эксперимент, в Adobe Audition 1.0 сгенерировал две частоты, сохранил их в .txt формате (тот же PCM, только блокнотом открывается) потом свёл и результат тоже записал. Теперь смотрю и не могу понять алгоритма сведения, это совсем не похоже на математическое сложение.

А там точно голый PCM ? Без всяких заголовков ? А то WAV файл содержит заголовки и прочую служебную информацию, а об этом многие почему-то забывают. И В WAV можно хранить необязательно в чистом PCM, можно использовать адаптивные PCM, да и вообще любые другие ( В WAV нужно убедиться, что 20-21 байты содержат 0х0001 )

И ещё, я не знаю, как там в том .TXT, но .WAV данные пишутся в little-endian формате, т.е. в обычном HEX редакторе байты данных будут "перепутаны местами".

vitalik_1984 писал(а):звук то такой разрядности все равно не будет

С чего это не будет?
Поясните мысль.

Cheba писал(а):В 16-бит WAV звук хранится в знаковом представлении. 0x7FFF+0x7FFF (два самых громких звука в положительной полуволне) при арифметическом сложении дадут 0xFFFE,

А я и не предлагал арифметически складывать Я говорил про результат, про который раньше писали. Тем более кто вам вообще сказал что так нужно считать? Это вы считаете как беззнаковое. И речь шла о дополнительном разряде при подсчете. Ваш результат является выходом за область значений данного типа( новый разряд).
Я же предложил не выводить новые разряды, а избавляться от них сдвигом
звук=(0x7FFF+0x7FFF)>>1
Какой тогда звук будет? Логично предположить что и получится самый громкий звук так как два одинаковых значения сложили и поделили на два
Самым громким звуком при двух каналах как раз и будет тот, при котором в обоих каналах максимум разве не так?

Dmitry Dubrovenko писал(а):С чего это не будет?
Поясните мысль.

Ну смысл вам придумывать новые мельницы и охотиться на велики? Есть 16 битный звук. Есть второй такой же. Сложили получили 17 бит. Как его выводить? при 16 бит хватает для хранения/использования одного семпла двух ячеек памяти как оперативной так и регистров. А 17? лишний байт из-за одного бита? не рационально как то.

vitalik_1984 писал(а):Это вы считаете как беззнаковое.

Очень даже знаковое. И всё правильно считается.
Распишите 0xFFFE в 17-битном представлении, и увидите, что это именно так.

vitalik_1984 писал(а):А 17? лишний байт из-за одного бита? не рационально как то.

Ну, вообще-то и 24-битный звук используют.
Разумеется можно и понижать разрядность, но просто отбрасывать младшие разряды нельзя.

Большое спасибо за ответы, как я понял необходимо арифметически складывать побайтно и делить на 2.

Мне нужен именно 16 - разрядный звук, т.к. шим у меня тоже 16 - разрядный.

Я так и делал, складывал два семпла (с флагом переноса получается +1 разряд), потом сдвигал вправо (перенос попадал в старший бит семпла). Для двух звуков вполне прокатывает, но при этом если воспроизводится только один, то его сила в 2 раза меньше. Для 3 и более получалась фигня, т.к. один звук воспроизводился очень тихо.
P.S. использовалась 8-битная ШИМ.

Тогда нужно каждый раз делать проверку сколько звуков воспроизводиться и складывать. У меня задача ещё сложнее - надо смешивать звуки в разных соотношениях. Думаю, сначала умножать на коэфиценты (сумма которых будет равна 1), а затем складывать.

Kashey писал(а):Тогда нужно каждый раз делать проверку сколько звуков воспроизводиться и складывать.

Это если звук(и) начинает(ют) и заканчивает(ют) воспроизводиться одновременно, тогда годится. Но если один из звуков прекратится, то второй резко станет в 2 раза громче
Вот в этой теме я пытался сделать что-то, там и несколько ссылок есть на алгоритмы.

Kashey писал(а): У меня задача ещё сложнее - надо смешивать звуки в разных соотношениях. Думаю, сначала умножать на коэфиценты (сумма которых будет равна 1), а затем складывать.

Если сообразить как правильно смешать хоть 2 звука, то их количество и соотношение уже будет делом простого "удлинения алгоритма"...

Engineer_Keen писал(а):Вот в этой теме я пытался сделать что-то

Во-во.
В той теме всё и обмусолили уже.
И про алгоритмы, и про громкость.

А звук надо сводить аналогово Цифра - зло
Чуть ли не любой операционник может обеспечить 100дБ динамического диапазона, и прекрасно сложит и два, и N сигналов. Без всякой сложной математики.

Dmitry писал(а):Очень даже знаковое. И всё правильно считается.
Распишите 0xFFFE в 17-битном представлении, и увидите, что это именно так.

0 1111 1111 1111 1110 это отрицательное число?

vitalik_1984 писал(а):0 1111 1111 1111 1110 это отрицательное число?

Откуда должно взяться отрицательное число, если складываются два максимальных положительных?

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

vitalik_1984 писал(а):я писал в ответ на это

Но вы же начали разговор, что разрядность увеличивать не надо, на что Вам ответили, что иначе, вместо положительного получается отрицательное число.
После чего Вы сказали, что арифметическое сложение не подходит.
Разве не так?