Программный MIDI-синтезатор для Windows, который работает как VSTi-плагин. Поддерживает расширения Yamaha XG и Roland GS, что является уникальной особенностью S-YXG50. Был частью пакета Yamaha SOL2. Yamaha прекратила поддержку данного программного синтезатора в 2003 году, поэтому была создана переносимая версия этого VSTi, не требующая установки и ключей в реестре. Используется встроенная в ресурсы DLL-файла официальная 4MB-версия wavetable, лучше которого для S-YXG50 не выпускалось.
Скачать: yamaha_syxg50_vsti.7z (3.0MB).
Что нового в этом патче?
- Не требуется установка. SYXG50.DLL теперь всегда читает файлы из своей директории.
- Файлы таблиц звуковых данных расшифрованы и сохранены в ресурсах DLL-файла.
- Если же их удалить из ресурсов, то VSTi будет искать их в своей директории (SXGBIN41.TBL, SXGWAVE4.TBL).
- Полностью удалён антиотладочный код, код проверки серийного номера и код trial-режима.
- Скрытые настройки читаются из ini-файла с именем, аналогичным имени dll-файла, но с расширением ini.
- По умолчанию лимит полифонии равен 128.
- Более частые обновления информации в GUI.
- Кнопка Help будет спрятана, если нет файла SYXG.CHM.
- Мета-информация VST находится в ресурсах (String Table), поэтому при необходимости её можно легко изменить.
- GUI может быть выключено и ресурсы GUI могут быть удалены, в результате чего этот VSTi будет работать как SGP.DLL.
Этот патч никак не влияет на синтез звука оригинального VSTi. Это было протестировано на сотнях MIDI-файлов, чтобы убедиться, что вывод побитово идентичен оригинальному S-YXG50 VSTi с теми же настройками.
Как использовать
Для проигрывания MIDI при помощи этого синтезатора необходимо настроить какой-нибудь VST-хост. В качестве него может выступать ваш любимый плеер, только нужно найти соответствующий плагин. В качестве примера ниже приведено несколько инструкций. Для проверки корректности настройки послушайте bi2_polkovnik.mid (35KB) — он должен звучать идентично записи bi2_polkovnik_syxg50.ogg (2.0MB).
VSTi MIDI Driver (как системный MIDI-синтезатор)
VSTi MIDI Driver позволяет использовать любой VSTi как глобальный системный MIDI-синтезатор. В данном случае каждая игра или MIDI-плеер, которые используют стандартный системный MIDI-синтезатор, будут использовать Yamaha S-YXG50 VSTi.
- Установите Falcosoft VSTi MIDI Driver.
- Если у вас Windows 8 и новее, также установите Coolsoft MIDI Mapper.
- Скопируйте syxg50.dll из yamaha_syxg50_vsti.7z в любой каталог.
- Откройте настройки VSTi MIDI Driver, нажмите кнопку Load VSTi и выберите syxg50.dll.
- Откройте MIDI Mapper и выберите VST MIDI synth в выпадающем списке Default MIDI synth.
- Готово! Yamaha S-YXG50 VSTi будет использоваться как системный MIDI-синтезатор по умолчанию.
Yamaha S-YXG50 WDM (официальный драйвер только для Windows XP)
VSTi MIDI Driver поддерживает Windows XP/Vista/7+, но на Windows XP лучше использовать официальный Yamaha S-YXG50 WDM-драйвер, который можно скачать с серверов Microsoft Windows Update: 4MB-версия (лучше качество, расходует больше ресурсов), 2MB-версия (хуже качество, расходует меньше ресурсов). Установка этого WDM-драйвера производится вручную при помощи мастера установки оборудования в панели управления. Не забудьте выбрать Yamaha S-YXG50 как синтезатор MIDI по умолчанию в системных настройках звука. Когда используется Yamaha S-YXG50 WDM, в VSTi версии этого синтезатора нет необходимости.
foobar2000 (лучший плеер для тех, кто влюблён в музыку)
foobar2000 не использует системный MIDI-синтезатор, но это не является недостатком. Это позволяет использовать Yamaha S-YXG50 VSTi без установки драйверов в систему, что более надёжно.
- Скачайте и установите плагин foo_midi с сайта foobar2000.
- Создайте в каталоге foobar2000 подкаталог с именем vsti и скопируйте в него файл syxg50.dll из yamaha_syxg50_vsti.7z.
- Откройте в плеере настройки, Advanced → Playback → MIDI Decoder → VSTi search patch, укажите в этом поле полный путь до созданного вами подкаталога vsti, после чего примените изменения и перезайдите в окно настроек.
- Перейдите в Playback → Input → MIDI synthesizer host. В выпадающем списке plug-in выберите Yamaha S-YXG50, примените изменения.
- Готово! Теперь MIDI в foobar2000 будут воспроизводиться при помощи Yamaha S-YXG50.
Ссылки
- yamaha_syxg50_vsti.7z (3.0MB) — версия со встроенным 4MB wavetable, для обычного использования.
- yamaha_syxg50_vsti_ext.7z (4.0MB) — версия с внешними 2MB и 4MB wavetable, для экспериментов.
- bi2_polkovnik.mid (35KB) и bi2_polkovnik_syxg50.ogg (2.0MB) — MIDI и пример его корректного звучания для проверки корректности настроек вашего плеера и работоспособности самого VSTi.
Alexys, тут я тебя немного поправлю, в YAMAHе есть такие настройки, аналогов которых в SF2 нет, а некоторые я вообще впервые вижу (касается синтезаторной части), т.е. если даже и получится как то собрать в ручную SF2 на YAMAHовских семплах, то как YAMAHA этот SF2 всё равно звучать не будет. Нужно как нибудь нам будет связаться, я обновил проект, и показать тебе как они работают, может сможешь распознать некоторые из них, а если нет, то хотя бы попробуем их правильно описать.
Alexys,
Речь о том, что если вы запишете, например, 5 разных звуков подряд, в один общий файл с сырыми данными всех звуков, а потом начнёте менять частоту дискретизации, то ресемплер не будет знать, где начало и конец каждого звука, и будет интерполировать (в простейшем случае) последний семпл предыдущего звука с первым семплом следующего звука в сырых данных. То есть при увеличении частоты дискретизации вдвое будет добавлен дополнительный лишний семпл с неправильной амплитудой между каждой парой звуков. Trancein говорил об этом же.
Пример, для наглядности. Вычисления аналогичны тем, что были тут.
Представим, что у нас есть пара звуков в формате 22050/8:
0x55 0x53 и 0x20 0x24
Мы их записали в один файл подряд:
0x55 0x53 0x20 0x24
Конвертируем в 22050/16:
0x5555 0x5353 0x2020 0x2424
Конвертируем в 44100/16:
0x5555 0x5454 0x5353 0x3939 0x2020 0x2222 0x2424
Получили один лишний семпл 0x3939, который никак не связан ни с первым звуком, ни с вторым. Это среднее между последним семплом первого звука и первым семплом второго звука.
В зависимости от алгоритма, который будет использоваться для изменения частоты дискретизации, кроме лишнего семпла с мусорным значением, значения соседствующих с ним семплов тоже могут немного измениться в неправильную сторону.
VEG, Но, ведь речь то идет не об одном, а о нескольких файлах.. «G~Lí†ch» то говорил о непрерывности файла, а не о непрерывности звука. Да, даже, если и звуки записаны в файле прерывисто, то это не означает, что данные там прерывисты, это означает, что амплитуда в некоторых местах имеет значения нуля.
Вот поэтому звуки в банке записаны через некоторые промежутки по три-пять байт.
С этим согласен.
Alexys, ну в файле с сырыми звуковыми данными записаны же все звуки подряд. Если скармливать всё это целиком в ресемплер — для него это всё будет один огромный звук, и обрабатывать он будет его соответствующим образом. Даже если там есть отступы между звуками — это значит, что ресемплер будет вставлять на границе с последним семплом звука и отступом лишний семпл, который будет средним между значением семпла и значением, записанном в отступе (например, 0x0000).
Вообще, по-хорошему, кроме того, что ресемплеру лучше скармливать отдельные звуки, хорошо бы научить его понимать и луп-регионы, чтобы он понимал, что за последним семплом данного звука будут воспроизводиться семплы из середины данного звука. Не знаю, есть ли такие. Возможно, можно применить обычные алгоритмы передискретизации, если перед изменением частоты дискретизации и обработкой (типа подавления шумов) предварительно продублировать луп-регион, а потом по окончанию обработки удалить из хвоста дубль луп-региона. Таким образом, во время обработки этого звука все используемые алгоритмы будут точно знать, какие семплы будут идти после последнего семпла.
VEG, а разве вы не ошибаетесь. Файл из 22050 8-бит в 44100 16-бит увеличивается ровно в четыре раза, и ни каких лишних и недостающих байт не получается. Привожу точный пример метода конвертации байт на основе вашего примера (0x55 0x53 и 0x20 0x24), при помощи Wavosaur. Именно этим методом я и конвертировал весь банк одним файлом, который получился без единого щелчка, вначале я конвертировал разрядность, а после ч.д. с применением Polynome 2nd Degrees интерполяции.
Берём : 55 53 20 24 , конвертируем из 22050 8-бит в 22050 16-бит (Process\Bit depth converter), и получаем AA D4 A6 D2 40 9F 48 A3 , размер увеличился ровно вдвое т.к. теперь разрядность описывается двумя байтами. Далее конвертируем из 22050 16-бит в 44100 16-бит (Process\resample), и получаем размер ещё в два раза больше : 20 BF 20 BF 40 9F 57 9A 48 A3 8E C6 00 00 97 0B , т.к. теперь стало отсчётов в два раза больше.
Alexys,
И опять пример. Имеем звук 22050/16, который должен проигрываться по кругу (луп-регион размером в весь звук):
0x5555 0x5353
Если просто прогнать его через ресемплер, получим:
0x5555 0x5454 0x5353
Если мы попробуем проиграть его по кругу, выйдет:
0x5555 0x5454 0x5353 0x5555 0x5454 0x5353
Если же перед ресемплингом исходный звук продублировать:
0x5555 0x5353 0x5555 0x5353
То в 44100/16 получим:
0x5555 0x5454 0x5353 0x5454 0x5555 0x5454 0x5353
Отсекаем хвост с дублем лупа:
0x5555 0x5454 0x5353 0x5454
Зацикливаем:
0x5555 0x5454 0x5353 0x5454 0x5555 0x5454 0x5353 0x5454
Получилось гораздо лучше. Нет потерянного семпла и скачка, который получался, когда мы не дублировали луп-регион.
Wlad, вы уверены, что у вас 8 и 16 бит не в разных форматах (signed/unsigned)? Уж слишком разные числа у вас получились, не похоже на правду. Также, возможно, 16-бит у вас little endian, то есть при записи в человекопонятном виде порядок байт в парах нужно менять.
Сейчас сам попробую.
Вы правы, Unsigned в Signed.
Я всего лишь привел точный пример того, как конвертировался сам банк, и что увеличение размера после каждой конвертации происходит ровно вдвое. Самое интересное ещё то, что после конвертации банка из 22050 8-бит в 22050 16-бит, файл увеличился всё же на два байта, а с 22050 16-бит в 44100 16-бит ещё на два, в итоге получается четыре лишних байта на весь банк (в Audition тоже самое).
Размеры файлов до конвертации, и после :
dsxgwave (Unsigned) 22050 8-бит - 2.417.446
dsxgwave (Signed) 22050 16-бит - 4.834.890
dsxgwave (Signed) 44100 16-бит - 9.669.780
Теперь можно попробовать только с Unsigned такое сделать, сейчас также попробую это сделать.
Прошу прощения, допустил ошибку, размер банка увеличивается ровно вдвое !
dsxgwave (Unsigned) 22050 8-бит - 2.417.445
dsxgwave (Signed) 22050 16-бит - 4.834.890
dsxgwave (Signed) 44100 16-бит - 9.669.780
После Wavosaur при конвертации в 16 бит я получил (при экспорте надо указывать 16 bit, unsigned, big endian):
0x54A9 0x52A5 0x1F3F 0x2347
Не могу сказать какой алгоритм Wavosaur использовал для этих целей, но выглядит результат не очень хорошо, звук явно стал немного тише. Впрочем, это уже похоже на полученное мной по описанной формуле:
0x5555 0x5353 0x2020 0x2424
Для примера взял SoX (к слову, в этой утилите доступен один из самых лучших ресемплеров, с исходным кодом), выполнил команду для преобразования в 16 бит:
Получилось:
0x5500 0x5300 0x2000 0x2400
Авторы SoX использовали описанную мной формулу, только делят число на 256, что некорректно (я обосновывал почему ранее) — нужно будет написать авторам баг-репорт. Я сам попадал в эту ловушку и допускал такую ошибку недавно, когда в патче для NFS3 делал конвертацию цветов для каждого кадра видео в формате RGB565 (16 бит) в формат RGB888 (24 бита). На картинке эта ошибка проявлялась в виде более тёмного изображения, чем было изначально. В случае со звуком эта ошибка даст более тихий звук, но разница будет меньше 0.5%, поэтому на слух её не слышно.
С ресемплерами всё гораздо сложнее. Тот примитивный алгоритм интерполяции, что я описал, вряд ли где используется. У ресемплеров стоит задача добиться прозрачного звука, а не сохранить исходные байты. Тем более, что изменение частоты дискретизации легко может быть не кратным. В общем, правильные ресемплеры работают со всей волной сразу, а не работают тупо с парами семплов, и они не должны показывать результат близкий к тому, что я показал у себя в примере. Но стыки между звуками всё равно будут искажать результат, так как ресемплеры будут стараться передать прозрачное звучание именно этого перехода между звуками, будто оно так и будет воспроизводиться, когда на самом деле в этом месте луп, о котором ресемплер ничего не знает.
Вот что у меня получилось в Unsigned, big endian.
55 53 20 24
54 A9 52 A5 1F 3F 23 47
3F 1E 3F 1E 1F 3F 1A 55 23 47 46 8D 80 00 8B 97
Ну а теперь для сравнения проделайте то же самое раздельно с звуками 0x55 0x53 и 0x20 0x24, когда это два отдельных файла. И потом сравните, что выдаст вам ресемплер с тем, что у вас получилось, когда вы два этих звука преобразовывали одним махом, будто это один звук. По идее, результат должен быть разным.
Никакой разницы.
55 53 - 20 24
54 A9 52 A5 - 1F 3F 23 47
Wlad, никакой разницы и не должно быть для изменения разрядности. Проблема должна возникать при изменении частоты дискретизации (для большинства алгоритмов, по крайней мере). То есть, вам нужно ещё в 2 раза поднять частоту дискретизации каждого из этих двух файлов. Вот это и нужно будет сравнивать с тем, что у вас получилось в первый раз.
Верно, получился совсем другой результат.
63 67 63 67 80 00 85 AB - 46 8D 46 8D 80 00 8B 97
всем привет
вег,влад к какому выводу-то пришли?
при переходе от 22050Гц к 44100 появляются лишние отсчеты которые приводят к щелчкам в loop-ах или что?
best_italo, к тому что resample(A+B+C) не то же самое что resample(A)+resample(B)+resample(C) для большинства алгоритмов изменения частоты дискретизации. Эта же проблема будет проявляться для любой обработки звука, где работа ведётся не с каждым семплом в отдельности (как при преобразовании 8 бит в 16 бит), а где работа ведётся целиком с волной (эффекты, шумодавы и т.д.). Можно предположить, что это может быть причиной щелчков, но наверняка утверждать это не берусь. Разница может быть и неслышимой.
ошибаетесь вег
допустим у нас записаны подряд семплы(образцы) гитары и флейты
у этих образцов есть метки начала и конца и есть метки начала и конца loop-ов
вот относительно этих меток и надо ориентироваться
все что за пределами этих меток абсолютно нигде не учитывается и там может быть хоть один отсчет хоть десять
т.е. метки можно рассматривать как указатели на адреса
и то что в случае передискретизации с 22050 на 44100 между этими указателями и отсчетами появляются дополнительные промежутотные значения (имеется в виду то что внутри между метоками) - абсолютно ни на что не влияет, кроме как на сглаживание переходов между отсчетами
так что влад был ближе к истине но потом почему-то повел себя как-то неуверенно
видимо сказывается недостаток знаний - отсюда и неуверенность
best_italo,
Такое впечатление что вы не заметили результаты теста, что Wlad привёл тремя сообщениями выше. Лишний семпл был бы в том алгоритме с простейшей интерполяцией, который я описал для наглядной демонстрации проблемы (потому что хоть о проблеме и упоминали тут несколько раз, всё равно не всем было понятно, о чём речь). Но этот алгоритм в реальности не используется. Используются более сложные алгоритмы изменения частоты дискретизации, которые работают не с парами семплов, а целиком с волной (то есть затрагивают сразу много семплов), и об этом я тоже тут писал. Таким образом, начало следующего звука будет влиять на конец предыдущего звука, поскольку алгоритм изменения частоты дискретизации будет пытаться передать звучание этого перехода между звуками. Что Влад и продемонстрировал, проведя эксперимент.
Проблемы не будет, если при повышении частоты дискретизации вдвое просто дублировать значение каждого семпла дважды. Но это худший алгоритм передискретизации в принципе и он даст скорее всего неприемлемый результат.
я все прочитал вег и неоднократно упоминал про метки на которые вы почему-то не обращаете внимания
ну хорошо давайте сделаем так:
сделайте в Adobe Audition или в WaveLab-е (другие нежелательны в виду их меньшей профессиональности) образец того о чем вы пишите - это и будет ярким и наглядным подтверждением вашей точки зрения
если вы плохо знаете эти программы то может и влад это сделать
он ведь достаточно хорошо понял о чем речь и сможет все это дело смоделировать
при желании потом это можно будет открыть и посмотреть в каком-нибудь HEX-редакторе
p.s. никого не хотел обидеть своими постами просто стало интересно и захотелось докопаться до истины
я ведь могу и ошибаться что в общем свойственно человеку
best_italo,
В обсуждаемом случае ресемплер ничего не знает об этих метках. Ресемплер обрабатывает весь поток звуковых данных так, будто он будет проигрываться именно в таком виде, где все звуки воспроизводятся один за одним. И на стыках между звуками ресемплер будет пытаться передать именно то звучание, какое было бы, если бы весь этот поток воспроизводился как единое целое. Соответственно, первые и последние семплы каждого звука в этом потоке будут немного отличаться от тех семплов, которые получились бы, если бы ресемплер применялся к каждому звуку в отдельности. Ощутима ли эта разница на слух — это отдельный вопрос, которого я не касаюсь.
Я уже достаточно подробно расписал. Не вижу смысла повторяться. Если вы действительно хотите разобраться — внимательно перечитайте написанное в предыдущих сообщениях.
Драматичность последствий от этой проблемы для конкретного алгоритма передискретизации можно оценить использованным выше способом. Нужно взять несколько длинных звуков, и сделать два варианта: resample(A+B) и resample(A)+resample(B). Результаты сохранить в raw/16 bit/unsigned/big endian. Это позволит с удобством сравнивать звуковые данные этих файлов любым инструментом для сравнения и поиска различий в двоичных файлах.
не в обиду вег, да забудьте вы про эти стыки, считайте что их нет а есть несколько файлов в одном, благодаря разметке
и что там знает или не знает ресемплер нас не должно заботить, главное мы все знаем благодаря разметке
влад ведь не даром тратил столько времени на вычисление адресов звуков и loop-ов
следовательно относительно этих адресов разметки и организована вся работа
Доброго всем дня.
best_italo, я ещё раз очень внимательно всё перепроверю и опишу все результаты, что бы быть уверенным на 100%, и к тому же Wavosaur как оказалось не корректно конвертирует разрядность влияя тем самым на звук, и на вышеприведённые результаты, а вот в Adobe audition такого с разрядностью замечено не было, и после того как я конвертировал вчера разрядность банка в Audition, звук в синтезаторе стал немного другим, как мне показалось мягче что ли, и шум, хоть едва заметен, но стал менее выразительным. Вот этот синтезатор для оценки : https://yadi.sk/d/zRBxl9Km3LFuV7
best_italo,
Похоже, что вы даже не пытаетесь понять о чём речь. Речь не о том, что данные смещаются или что-то ещё. Речь о том, что сами значения семплов могут искажаться. Семплов, которые входят в области, отмеченные этими метками.
Trancein,
Движок S-YXG50 по умолчанию (без правок кода) поддерживает два формата семплов: 8-bit unsigned и 16-bit unsigned.
«G~Lí†ch»:
Alexys:
Alexys, где вы из моих слов видели, что я упомянул импортирование самих SF2 в ямаху? Посмотрите на окно редактора sfZed, там те же функции, что использует ямаха: eg (adsr), cutoff, reso, pitch, level, pan, effect1, effect2... Если каким-нибудь образом импортировать в sfZed какие-нибудь патчи из TBLицы, то из ямахи можно сделать те же патчи, только в sfz формате, которые очень любят некоторые
композиторы, музыканты и разработчики типаCakewalkTwelve Tone Systems и (Dimension, Rapture, Session Drummer).Но стоит упомянуть, что в sfZed точность таких настроек гораздо выше, чем в ямахе (нет ограничений в «битах»)... Поэтому при "упаковке" SFZ-шек назад в TBL-файл данные могут исказиться. А насчёт SF2-банками тоже
неплохая идея, но, я не уверен, что и онѝ не исказятся. В ямахе же как-никак ограниченное количество бит на определённую настройку. Это просто как "упрощённая" альтернатива сэмплера TX16Wx.А вообще, какого
битачёрта вы из 8-бит конвертируете? И вообще, какой смысл работать с некачественным «сырьём» (шлаком/браком)? Мало того, что выбрали банк 22050, да ещё и с ограниченным уровнем [-127;0;+127].А "ваш алгоритм" Polynome 2° при конвертации ПИЛЫ делает практически то же, что и Sound Forge. Конечно, при преобразовании с 8 бит в 16, мы получим
"погнутые зубы пилы"такой же результат, а вот при конвертации из 22050 в 44100 мы получим "крюк" после резкого спада в определённую фазу.best_italo, Аудишн
гадёнышв файл вписывает слишком много лишней мета-информации, из-за которой САМ ЖЕ АУДИШН этот файл иногда ОТКАЗЫВАЕТСЯ ОТКРЫВАТЬ :)! А как его отучить от этого, пока не понятно.Но то, что происходит с пилой в WaveLab-е, просто ужас. Сгенерировл пилу на уровне 80% в 22050, 8 бит, после конвертации в 44100 она "на углах" загуляла, и почти ДО ПИКА (98%) выстреливает в двух фазах.
Из этого следует, что единого алгоритма апсемплирования для всех сэмплов не существует, и к каждому сэмплу нужно применять отдельный алгоритм.
вег, вы немного изменили суть полемики
вот цитата из вашего поста #902
а это цитата из вашего поста #923
что касается второй цитаты то значения семплов при ресемплинге естественно подвергаются какому-то пересчету и изменению
но ведь эти изменения делаются равномерно по всему этому длинному (или большому) файлу а не конкретно где-то на стыках или в конце
так что это можно даже не брать во внимание (если конечно я вас правильно понял)
и почему-то вег вы упорно не хотите смоделировать то о чем пишете
эти аргументы ведь было бы не сравнить ни с какими словами или объяснением на пальцах
ну вроде как влад заинтересовался этим экпериментом, я думаю он или полностью или частично всех рассудит
а какое отношение к нашей дискусии имеет 8 битный или 16 битный беззнаковый формат?
тоже ведь для убедительности нужно моделировать ситуацию и "ткнуть носом" а так это все слова
VEG,
ответ на пост 904.
Абсолютно с Вами согласен, что ресемплер будет обрабатывать весь звук, как весь, а не раздельно. Я понимаю, что «G~Lí†ch» имел в виду именно это, но говорил то он о разрывности данных, чего не может существовать в одном файле. Т.е. если есть разрывы, то это уже разные файлы.
Насчет ресемплирования отдельных файлов, то тут тоже особо придумывать нечего, поскольку, например, та же Awave Studio имеет возможность batch-обработки. Можно класть сколько угодно файлов. Проблема здесь только в подготовке этих звуков. Одно дело, когда сам, изначально набираешь весь банк, идя медленно и скрупулезно и совсем другое, когда имеется уже готовый банк, который достаточно БЫ обработать в пять секунд. Но вот тут загвоздка, потому что не очень хочется его резать на полторы тысячи фрагментов.
Не думаю, что требуется учить ресемплер понимать, где какие важные пользователю точки стоят в звуке. Луп-регион - это такое же абстрактное для "цифры" понятие, как и угол атаки, как фронт спада. Это уже касается только полезного сигнала, т.е. самого звука, его временнЫх характеристик, где не столь важно какой ЧД и битностью этот сигнал определен.
Ответ на пост 906.
Наоборот, при появлении последнего отсчета 0х5454 в последовательности 0х5555 0х5454 0х5353 0х5454 появится щелчок, поскольку он мало того, что дополнительный в цепочке, так еще и имеет некоторое значение. Если звук достаточно длинный и имеет свою фазу перехода в регионе, то такой отсчет создаст дополнительные искажения в звуке, что на слух и будут восприниматься как щелчки. А вот для простейших коротких сигналов это не важно, так как этот отсчет создаст только дополнительные гармоники, что является более положительным свойством (чем больше искажений, тем богаче звук тембрально).
Ответ на пост 909
Wavosaur Вам выдал верный результат.
Я еще тогда обратил внимание, когда Вы приводили пример с ресемплингом, где делили 255 на 255. Все-таки это не так - делить надо на 256. Ведь чисел то всего 256, а не 255. Да, верно, последнее значение - 255, но всего чисел 256. А значит все математические операции производятся со всем числовым рядом, а не с последним значением этого ряда.
Например в зрительном зале ряды стульев. (приводж этот пример уже в десятый раз, наверное, каждому по отдельности...) Стульев в ряду всего 20. Нумерация начинается от нуля. Каким по номеру будет последний стул ? Правильно - 19-й. Но стульев то 20.
Также с иными числовыми рядами. 0 1 2 3 4 5 6 7 8 9 - сколько чисел ? Правильно - 10.
Поделим все эти ряды пополам.
256 - 128, 20 - 10, 10 - 5.
А под каким номерами будут эти числа ?
Правильно в 256-и будет 127-й, в 20 стульях будет 9-й, а в десятке будет 4-й.
Т.е. вылазит пресловутое n - 1 для ряда с нулем.
А Вы говорили, что делить надо 255 на 255. А что тогда будет половиной ? 127,5 ? Нет, конечно. Числа должны быть целые.
Поэтому заключение, что 255/256 - верно. Это будет действительно 0,99609375 (конечное, кстати, число). Т.е. значение действительно немного меньше единицы.
Скорее всего программы об этом знают и добавляют недостающее число, если есть необходимость. Хотя, врядли регистры имеют верхний пустующий разряд.
Возможно многие скажут - "а как же клиппинг звука, возникший в результате обработки ? Ведь это увеличение амплитуды ?" Да, верно, это увеличение амплитуды. Но никто ведь не говорит, почему-то, какой разрядности сами обработчики, а ведь чаще всего они 32-битные, где возможно создать запас по амплитуде. Кроме того, амплитуда сигнала здесь - понятие относительное.
Влад сказал:
Что и подтверждает теорию о числовом ряде n - 1.
И VEG, пожалуйста, поправьте шрифт в поле набора текста, а то из-за смещения курсора порой делаешь глупые ошибки. Трудно определить количество пробелов при наборе текста - то ли их два, то ли он вообще отсутствует.
best_italo, ну так дочитывайте цитируемые сообщения до конца. Даже в том что вы процитировали есть отсылка, что я говорю именно о приведённом мной простейшем методе интерполяции (там написано «в простейшем случае»). А чуть ниже в этом же сообщении я написал:
И дальше, в последующих сообщениях, я повторял это несколько раз, причём делал упор уже именно на искажения значений семплов. Потому что реально используемые алгоритмы передискретизации далеки от наивной интерполяции, которую я использовал для наглядной демонстрации проблемы, о которой говорили другие люди на предыдущей странице. Они могут не ограничиваться парами соседних семплов, как было в моём примере, они могут могут работать с волной целиком, учитывая при работе сразу большое количество семплов. О чём я тоже писал.
Потому что я представляю какого результата стоит ожидать. Я вклинился в разговор лишь с целью объяснить на доступных примерах, о какой проблеме говорили предыдущие ораторы. У меня нет цели убедить вас, что проблема имеет место быть. Если мои примеры не делают обсуждаемую проблему очевидной для вас — можете сами себе провести ряд экспериментов. Ну или и дальше игнорировать её. Как я тоже уже писал, эти искажения могут быть и неслышимыми вовсе.
Это было адресовано не вам, а Trancein. Цитата взята с предыдущей страницы, которая к текущей дискуссии отношения уже не имеет. Речь лишь о том, что для оригинального движка S-YXG50 можно сделать банк с 16-битными семплами, и он будет работать. Wlad на предыдущей странице делал демонстрационные банки в несовместимом с оригинальным движком формате. Можно было бы подумать, что оригинальный движок не имеет каких-то возможностей для эмуляции YMF7xx. Но на самом деле это не так, и обсуждаемые на предыдущей странице банки можно было сделать и в совместимом с оригинальным движком формате. Не то чтобы эта информация имела какое-то решающее значение, просто маленькое дополнение.
Alexys может хватит уже строить из себя гуру?
давно читаю этот блог и честно говоря уже остонадоела ахинея которая почти в каждом посте исходит от вас глитча и ямахаюзверя
то что у нас здесь возникла дискусия по достаточно непростой теме которая лежит в области DSP, аудиопрограммирование и т.д. и т.п. еще ни о чем не говорит тем более если учесть что вег достаточно далек от музыки (если я ничего не напутал) и тем еще более что я допускаю что могу быть не во всем прав, поэтому и хотел поставить все точки над i
но то что вы в своем посте #926 позволяете себе вести полемику так как будто вы академик а вег первокласник, это уже извините ни в какие "ворота"
для начала советую позаниматься программированием лет 10-15 желательно еще и с заходом в реверсинг
насколько я правильно понял благодаря реверсингу вега мы все имееи возможность использовать Yamaha S-YXG50 на 7-ке и выше
p.s. еще раз хочу подчеркнуть что никого не хотел обидеть и советую вегу не тратить время на ответы тому бреду который очень часто исходит от Alexys и ему подобным
Alexys,
Я просто постарался пояснить суть указанной кем-то другим проблемы. Принимать это во внимание или нет — решать не мне.
Считать нужно не количество точек, а количество отрезков, на которые эти точки делят прямую от минимальной амплитуды до максимальной. Пример: 0_1_2_3_4_5. Точек 6, но отрезков — 5. Длина этой прямой от минимальной до максимальной амплитуды всегда одна и та же. В зависимости от разрядности, мы имеем разное количество точек на этой прямой. Чем больше разрядность — тем меньшие отрезки между точками. Значение семпла указывает на одну из точек на этой прямой. При повышении разрядности новое значение должно указывать в ту же самую точку (или максимально близкую) на этой прямой. Если вы будете делить на количество возможных значений (точек на этой прямой), то точки начнут сдвигаться влево и звук станет немного тише, что я уже вам демонстрировал.
Ладно, ещё один пример, с вещественными числами. Представьте, что минимальная амплитуда — 0.0, а максимальная — 1.0. То есть это отрезок от нуля до единицы. Чтобы преобразовать unsigned int любой разрядности к этому виду — нужно просто разделить текущее значение семпла на максимально возможное значение семпла для текущей разрядности. То есть для 8 бит делим на 255, а для 16 бит делим на 65535. Это число — от нуля до единицы — опишет, куда именно попала наша точка на прямой. При конвертации из 8 бит в 16 бит точка на прямой должна попадать в одно и то же место, то есть после преобразования 8-битного и 16-битного варианта в вариант с вещественным числом у нас должны получиться одинаковые или максимально близкие друг к другу числа. Если же окажется, что преобразованный в 16 бит семпл указывает далеко от исходного места, и если можно выбрать точку, которая ближе к исходной — значит преобразование было выполнено неверно.
Присмотритесь внимательно. Wavosaur явно использует другой алгоритм, так как его значения значительно меньше тех, которые были бы, если бы там было деление на 256 и умножение на 65536. Похоже, вы спутали Wavosaur с SoX. Именно SoX выдал такой результат, о котором вы говорите.
Я наверное сейчас открою вам большую и страшную тайну про цифровой звук. В знаковом 8-битном звуке минимальное значение -128, а максимальное — 127. Середина — на нуле. В знаковом 16-битном звуке тоже «середина» смещена: допустимы значения от -32768 до 32767. Чтобы сделать из таких семплов беззнаковые — нужно просто добавить 128 и 32768 соответственно. Но «середина» всё равно будет немного смещена. Для 8-битных семплов она будет на отметке 128, а для 16-битных семплов она будет на отметке 32768.
Ага, и для максимального значения амплитуды будет потеряно аж 255 пунктов (65280 вместо 65535). Но поднять весь сигнал на эти недостающие 255 мы не можем, потому что для минимальной 8-битной амплитуды 0x00 по вашей формуле выйдет 0x0000, и если вы начнёте что-то дополнительно двигать, то вы потеряете минимальную амплитуду.
Ну да, конечно, все программы при проигрывании 16-битного звука в первую очередь ориентируются на какой-то один алгоритм повышения разрядности с 8 до 16 бит, и корректируют все значения семплов на лету. Вы это серьёзно? Ну то есть вы серьёзно полагаете, что при проигрывании материала, изначально предоставленного в 44100/16, всегда применяется некоторая коррекция, которую вы придумали из-за некоторого несоответствия, которое возникло при конвертации из 8 бит в 16 бит по одному из алгоритмов?
Представим, что у нас есть звук A, в котором есть луп-регион. Как этот звук должен проигрываться? Так, будто за последним семплом луп-региона находится первый семпл этого же луп-региона. Упрощаем. Считаем, что этот луп-регион должен повториться ровно 100 раз. Таким образом, звук A должен звучать так же, как если бы мы взяли этот звук A, продублировали бы в нём луп-регион 100 раз, а сами данные о луп-регионе удалили. Назовём такой звук, где луп регион просто продублирован 100 раз, A*. Согласны ли, что звуки A (при проигрывании с учётом луп-региона) и A* должны звучать идентично? Если да (а тут нет оснований считать иначе), идём дальше. Прогоняем звук A через ресемплер. Получаем resample(A). Так же поступаем с A* и получаем resample(A*). Согласны ли вы, что resample(A) должно звуачать максимально близко к идентичному с resample(A*)? Логично, что должно. Но в случае, когда ресемплер работает с обычным A, когда он занимается изменением частоты дискретизации конца луп-региона, не знает, что за этими семплами будут повторно проигрываться семплы из начала луп-региона. Поэтому он может установить не самые лучшие значения для последних семплов в луп-регионе, и результат окажется хуже resample(A*), где у ресемплера не было такой проблемы.
В моём примере с наглядной интерполяцией между соседними семплами, если вы сразу исходный звук продублируете 100 раз, а потом измените частоту дискретизации — то там между дублями всюду будут эти 0х5454. То есть в версии с луп-регионом 0х5454 должно в него попасть, и это не будет лишним семплом.
Это не будет лишним семплом также исходя из той мысли, что частота дискретизации у нас в 2 раза выше, и без этого «лишнего» семпла воспроизведение луп-региона ускорится аж на 25% (ведь вместо 4 семплов, которые должны были бы быть, у нас получится 3).
best_italo,
Я далёк от написания музыки и ничего в этом не смыслю. Но адекватное представление о самом цифровом звуке имеется.
Wlad
Cпасибо! Вот теперь и только теперь мы имеем чистые 16 бит ) шума ноль ) осталось сделать одним файлом и ляпота будет )
Влад , я нашёл нарушение луп региона.
Вот здесь https://yadi.sk/d/oNDzNoPG3LGSsx если проиграть миссию и прослушать композицию геймовера , то в конце когда начинается басовый такой звук , слышно что с лупом что-то не так.
Alexys, вот ты и дошёл до того о чём мы на old-games ) , только чуть позже )
VEG
Вы действительно сделали открытие , однако вовсе не то , которое хотели... дело в том , что если в 8-и битном звуке 256 возможных значений от 0 до 255 , то так называемая вами всередина 127 на самом деле на 1/256 левее чем должно быть. В общем-то я это ещё давно заметил что ровно середины в цифровом звуке нет , потому что чтоб была середина в тех же MIDI , значений должно быть не от -63 - левый до 64 - правый , а от -64 -левый до 64 - правый... таким образом получается что чтоб передать середину нужно 129 значений. При 128-и мы имеем то что считаем серединой по факту 1/128 левее чем середина.
YAMAHA User,
А теперь внимательно читаем, что у меня написано:
VEG, тут дело не в разрядности ) а в том , что сам цифровой звук в двоичной математике не может быть чисто монофоническим... какую бы разрядность вы не выбрали , хоть это будет 512 бит... вс равно смещение в лево будет. Чтоб такого не было , нужно было делать процессоры не с чётным числом данных 2/4/8/16/32 и так далее , а с нечётным 3/7/9/15/31 и так далее... потому что вот эта единица которая как бы не делится на 2 была бы ровно серединой между первой и второй симметричной половинками.
YAMAHA User,
Представим себе трёхбитное число. Максимально возможное значение — 7. Минимально возможное — 0. Середина всё равно будет смещённой. Она будет смещена независимо от количества бит в числе. Потому что количество возможных значений в любом целом числе с числом бит n — это двойка в степени n.
VEG
Проблемап в том , что вы рассматриваете 7 битное число в двоичной математике... а вы рассмаотрите например 9-и битное число в троичной математике где есть не два значения 0 и 1 , а как минимум три значения 0 , 1 и 2.
YAMAHA User, одна идея безумнее другой...
Пожалуйста, не решайте проблему которой не существует, в той области, в которой вы не являетесь экспертом. Программистам совершенно не мешает тот факт, что количество возможных значений у целых чисел всегда 2ⁿ.
Троичная система просто не прижилась, хотя трит гораздо эффективнее бита
Alexys, напомните пожалуйста, где я сказал о РАЗРЫВНОСТИ (прерывистоси) ДАННЫХ?
Читая Ваши посты, я сам начинаю верить, что эти маркеры "разрывают" аудио-данные. Однако, я ссылаюсь на потоковое аудио/видео, в которых это необходимо, и не внушаю себе то, что Вы себе внушили.
Несколько страниц ранее было сказано, что эти "маркеры" (для Вас я их назову "ссылки" ) указаны в таблице, а не в сэмплах. Да, я до сих пор читаю блог, поэтому стараюсь не упустить некоторые моменты. Поэтому я в курсе, что в самом файле никаких маркеров нет, а берутся из таблицы. Но я просто иначе объяснить не могу. Поэтому указал, что в этом месте начинается следующий сэмпл, или цикл-регион и выделил их специально МАРКЕРОМ, чтоб было понятно. А потом разъяснил, что алгоритму плевать на эти маркеры, соответственно на то, что это отдельный сэмпл, и зацикливающийся регион. С чего вы взяли о разрывности данных, дочитать до конца было лень?
Извините уж, что я объяснять не умею, если я что-то не так сказал, это не значит, что нужно понимать это по-другому.
Обновил синтезатор YmF-7x4 Final 44100-16bit Release https://yadi.sk/d/c08fJIF73J4KNx
Wavosaur не корректно конвертировал разрядность, из за чего звук получался не очень хорошего качества. После изменения программы для конвертирования разрядности, лично на мой взгляд,, звук стал мягче, чище (уменьшился шум), лучше слышно стерео панораму, а также стал выразительнее, и вроде как появился некий обьём. (слушал в наушниках, по этому 100% точно описать не могу, возможно в чём то и ошибаюсь)
Разрядность конвертировал с 8 бит в 16 в Adobe Audition 10, привожу примеры конвертации банка из 22050 8-бит в 22050 16-бит (байты были взяты с самого начала банка, т.е. нулевой семпл и далее).
Сразу видно что Adobe Audition 10 всё сделал правильно, а вот то что сделал WavoSaur, лично мне трудно понять.
Кстати, после ресемплинга с интерполяцией, код стал как бы так сказать более правильно выглядеть, т.е. не нагромождённый фиг знает чем (т.е. слишком плотный как к примеру в сжатом Zip архиве), а стал иметь как бы правильную последовательность :
влад все-таки более правильно было бы если б вы взяли по 2,5 - 3 периода разных, ну к примеру хотя бы синусоид
состыковали бы их, указали бы где находятся loop-ы (адреса) чтобы потом можно было бы сконвертировать и проанализировать
так же в дальнейшем можно было бы открыть и посмотреть это дело в Adobe Audition визуально
почему-то все упорно не хотят этого делать (видимо считают что все и так очевидно)
очевидно это как раз когда есть наглядный пример, есть конкретные адреса вот тогда есть за что зацепиться и есть что обсудить
влад я сделал два файла (wav) в Adobe Audition
один 8 бит на 22050 (с loop-ом) а второй это конвертация в 16 бит на 44100
поэксперементируйте может это поможет сделать какие-нибудь нужные выводы
https://www.sendspace.com/file/75cl7u
Хм, любопытно, выходит что Adobe Audition, как и SoX, поднимает разрядность с 8 до 16 обычным сдвигом на 8 влево (деление на 256 и умножение на 65536 эквивалентно просто умножению на 256, что в свою эквивалентно сдвигу на 8 влево). В багтрекере SoX создал соответствующий тикет, но так как проект остановился в 2015, ответа от авторов ждать не приходится, поэтому вскоре подниму соответствующую тему на HydrogenAudio, чтобы выяснить причины: или всем пофиг на маленькую неточность преобразования в эту сторону (всё же разрядность обычно понижают, со студийных 24 до обычных 16 бит), или есть всё же на это какие-то основания.
best_italo, хорошо, спасибо. Постараюсь сделать вечером более точный пример, если не успею, то завтра точно.
VEG, забыл сказать, что данные банка конвертировал из 22050 8-бит Signed, в 22050 16-бит Signed, а после ресемплировал в 44100 16-бит (с интерполяцией) соответственно в Signed. Взял изначально Signed из за того, что бы было наглядно видно что происходит с кодом, и из за того что с Unsigned форматом возникают некоторые сложности, и мало какие проги работают с ним.
VEG, мне не пофиг на маленькую неточность преобразования, вопрос в другом, какой должен быть на самом деле результат ? т.е. не могли бы вы наглядно в байтах показать, или тот припер который находится выше является правильным ?
т.е.
0x55 0x53 0x20 0x24
Конвертируем в 22050/16:
0x5555 0x5353 0x2020 0x2424
вег а может это делается специально для упрощения алгоритма?
там в принципе-то если я не ошибаюсь дело только в чуть меньшей амплитуде файла
при желании, кому нужно могут же сделать нормализацию
best_italo, ну да, в этом случае разница для максимальной амплитуды выходит меньше 0.4%. Но люди с аудио часто и не по таким мелочам загоняются. Сравнению алгоритмов передискретизации (SRC, Sample Rate Converter, Resampler — это всё одно и то же) кто-то даже целый сайт посвятил. Там на картинках намеренно принята шкала, которая ярко демонстрирует шумы далеко за пределами восприятия человеческим ухом. То есть тут люди загоняются даже с теми вещами, которые невозможно услышать :)
Недавно на HA был небольшой спор с автором Opus как раз по этому поводу. В кодер Opus встроен ресемплер из Speex, и он немножко хуже того, что есть в SoX. Разницу невозможно уловить на слух, но можно определить с использованием соответствующих инструментов. Что ещё более интересно — ресемплер SoX ещё и более быстрый. И исходники есть. Поэтому призывали автора Opus включить в состав ресемплер из SoX. Но автор Opus сказал что раз уловимой ухом разницы нет, то и шевелиться нет смысла. Впрочем, я считаю, что небольшое ускорение всё же было бы полезным. Но там ещё проблема с лицензиями — лицензия SoX не совместима с лицензией Opus. То есть надо ещё как-то достучаться до авторов SoX и просить у них разрешение использовать их ресемплер в коде Opus под лицензией Opus.
Wlad, если представить, что амплитуда — это прямая от 0.0 до 1.0 (от минимальной до максимальной амплитуды), то выйдет, что любые целочисленные форматы семплов просто указывают на какую-то точку на этой прямой. Значение этой точки будет определяться по формулам value8/255 для 8 бит и value16/65535 для 16 бит. То есть если имеем 8-битный семпл 255 (максимальное для 8 бит значение), то он попадёт ровно в точку 1.0. Соответственно семпл 0 попадёт ровно в 0.0. Если у нас имеется какой-то 8-битный семпл, и мы хотим подобрать для него соответствующий 16-битный семпл, нам нужно добиться того, чтобы они указывали на одну и ту же (или максимально близкую) точку на прямой от 0.0 до 1.0. То есть value8/255 должно быть равно или максимально близко к value16/65535. value8 нам известно. Математика проста:
В SoX и Audition же почему-то делается:
Но если вы попробуете посмотреть, куда будет попадать полученная таким образом точка на прямой от 0.0 до 1.0, то заметите, что она всегда будет попадать левее исходной точки (исключение для семпла со значением 0). Причём чем больше значение семпла — тем больше будет сдвиг. Да, ошибка мизерная и вряд ли её можно услышать, в среднем 0.2%, до 0.4% в худшем случае, но всё равно. Я обязательно создам пост об этом на HA, хотелось бы обсудить этот любопытный момент.
VEG, проблема в том, то программы для музыкантов пишут не музыканты, программы для дизайнеров не дизайнеры и т.п. В итоге получаем монстров типа GIMP, которыми пользоваться неудобно.
Типичная проблема в программировании графики и видео, например, заключается в том, что у нас значения в бинарном виде не линейные, а находятся в степенной зависимости (та самая «гамма дисплея») от кода в переменной языка программирования. Программисту, чтобы смешать два цвета, достаточно сделать среднее арифметическое, но видеться это будет неправильно, потому что график зависимости кода яркости от самой яркости не линейный. Или еще более страшная проблема, когда все расчеты делаются в 8-битном пространстве, где на выходе имеем truncate дробных значений и пастеризацию цвета. Очень многие программисты не заботятся ни качеством, ни удобством. Им удобно программировать, а на пользователей, для кого они пишут - это пофиг.
Другая проблема в том, что программисты не заботятся поиском наилучших алгоритмов по последнему слову исследований и достижений в предметной области. Например, вместо SoX они могут написать свой ресемплер на основе линейной аппроксимации. Тут есть беда с патентами и лицензиями, конечно, но я о другом.
Есть еще одна ерунда, связанная с программами - это маркетинг. Производителям программ хочется, чтобы пользователи покупали активнее, и стараются загнать в свои программы дополнительные фичи. Кажется, что все здорово, пользователь покупается, но когда начанает пользоваться, оказывается, что эти фичи сделаны тяп-ляп, а для реальной работы не годятся - слишком простые алгоритмы. Например, в аудиоредакторах есть функция шумоподавления. Вроде круто. Но настолько плохо сделано, что пользоваться нельзя - качество получается совсем низкое, по сравнению с тем, что могло быть, используя другие алгоритмы.
А касаемо преобразования уровней, разумеется, надо расширять на весь предельный диапазон. Опять же, скорей всего, программист сделал как ему удобно - просто дописал снизу нулей. А потеря уровней его не волновала, ему показалось, что это никому не понадобится, кому надо, пусть вызывает нормализацию и т.п.
Сейчас, кстати, сверх-конкуренция в ПО начинает давить на эти «традиции» и постепенно появляются программы, написанные для пользователей в их предметной области понимания бизнес-логики, с лучшими алгоритмами, с совсем иными подходами к работе.
Wlad, почему такая разница при изменении разрядности в WaveSour и Audition ?
Тут всё просто ) первый просто копирует 8-и битный сигнал в 16-и битное представлеие файла то есть сохраняет шумы и не применяет дизиринг. Второй же делает тоже самое , но через очень качественный дизеринг что значительно уменьшает шумность банка )
Может я описываю это топорным языком , но именно така мне представляется эта разница.
YAMAHA User, программа называется Wavosaur (вы постоянно называете её неправильно).
Здесь речь идёт о повышении разрядности, а не её понижении, то есть дизеринг лишён смысла. 8-битные семплы имеют однозначные соответствия в 16-битном пространстве.
Возможно, Wavosaur делает какую-то неожиданную дополнительную фильтрацию — тогда странно, что это не указано явно, и что это не настраивается. Потому что сама по себе операция повышения разрядности семплов достаточно однозначна, и любой другой результат по идее должен быть неожиданным.
Причём почему-то WaveSour даже скопировать бед подмешивания шума не смог как вижу ) , я думаю вам стоит ещё присмотреться к апсемплингу в Audition ) может там есть алгоритмы которые улучшают апсемплинг лучше чем у WaveSour )
VEG, надо понимать то , что ДЛЯ ЧЕГО делается повышение разрядности ) этот процесс делается с целью улучшения SNR , вот то что WaveSour скопировал сигнал из одного файла в другой причём так , что при этом ещё и подмешал в старшие биты какой-то шум - это плохо.
YAMAHA User, VEG объяснил же разницу. Вариант с Audition немного потерял в амплитуде и еще немного сместился по уровню. По факту не должно быть слышно никак, но если быть педантичными, то тот «улучшенный вариант банка» на самом деле ухудшенный.
Про улучшенное качество после дизеринга говорить не приходится никак. У нас исходник гораздо более худшего качества, чем 16 бит. Так что дизеринг тут что мертвому припарка. Дизеринг применяется, когда более качественный звук должен писаться в менее качаственных пределах. Например, когда у нас исходники в 32 бит 96 килогерц, то при преобразовании в 16-44 появляются ошибки. Дизеринг их распределяет между отсчетами или и вовсе их теряет в добавленном шуме. А у нас 8-битный звук расширяется в 16-битном, что увеличивает все ошибки округления в двести пятьдесят раз. На этом фоне ошибка вычисления отдельного отсчета совсем теряется. Только банк станет чуть шумнее и все.
Trancein, ну тогда перечитайте что показал Влад. Он показал :
Видно что Audition сохранил последовность : Смотрите сами :
было в 8 бит :FF FE FC FC 27 77 A3 F9 B8 2C F6 1E BE 11 16 EB
стало в 16 бит :
FF FE FC FC 27 77 A3 F9 B8 2C F6 1E BE 11 16 EB
А теперь поясните , как вот это :
52 49 46 46 70 C6 49 00 57 41 56 45 66 6D 74 20 12 00 00 00 01 00 01 00 22 56 00 00 44 AC 00 00Может оказаться качественней того что сделал Audition )
YAMAHA User, возникла путаница.
Изначально я понял неправильно то что вы имеете в виду. Вы говорите, что Wavosaur просто копирует 8-битные семплы в 16-битные (со сдвигом), а Audition применяет некую фильтрацию. Но судя по результатам экспериментов всё как раз наоборот: Audition прямо копирует исходные семплы без фильтрации (вероятно, с небольшой ошибкой, из-за которой максимальная амплитуда становится чуть ниже), а вот Wavosaur делает какое-то непонятное преобразование (и его звук получается ещё тише, чем у Audition).
YAMAHA User, судя по всему, первый вариант - это unsigned short, a второй вариант - signed short. Отрицательные числа пишутся несколько извращенно для глаза.