Apollo 37zv vs Foobar 0.9 vs Winamp 5.21

[moozooh]

Не всё так однозначно с битностью данных.
32х разрядным процессорам проще работать именно с 32х разрядными данными, переход на 16ти разрядные данные может не дать ускорения или даже замедлить работу.
Использовать 24х разрядное представление, с точки зрения производительности, может оказаться совсем бесполезным.

А не могли бы Вы мне объяснить, каким образом разрядность процессора связана с количеством бит, отводимых на сэмпл (если мы говорим о целочисленных форматах), или с точностью вычислений чисел с плавающей точкой?

[Иван]

Разрядность процессора - никак. :)

Но 32х разрядные процессоры действительно медленно справляются с 16 битными данными (потому что эти 16бит все равно загоняются в 32х разрядный регистр, а старшие 16 бит обнуляются.) Но это если только саму программу так написать, чтобы она работала с 16битными целыми, что вряд ли.

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

[moozooh]

Но 32х разрядные процессоры действительно медленно справляются с 16 битными данными (потому что эти 16бит все равно загоняются в 32х разрядный регистр, а старшие 16 бит обнуляются.)

Медленнее, чем с чем?

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

А ошибки округления при декодировании зависят от процессора? То есть если я буду декодировать на 32-битном и 64-битном процессорах один и тот же файл, то получу разные результаты, что ли? о_0

[Sunday]

В fb2k 0.8.3 было такое пояснение в ветке 'Playback':
Audio Processing pipeline: Decoder=>replaygain=>DSP=>convert to output data format=>output
в выпадающем меню под названием 'output data format' и выставлялась разрядность.
Вот по такой схеме и работает Foobar так-что независимо от того сколько вы там выставите, декодирование и обработка будут происходить по своему. (данная опция необходима т.к. на некоторых системах при завышеной разрядности звука может и не быть или он будет Очень искажён. как было на моём пребедущем компе)

[arcman]

moozooh

А не могли бы Вы мне объяснить, каким образом разрядность процессора связана с количеством бит, отводимых на сэмпл (если мы говорим о целочисленных форматах), или с точностью вычислений чисел с плавающей точкой?

Никак.
Кач-во не претерпит изменений при адекватной реализации.
Изменения относятся лишь к производительности в каждом конкретном случае.
32х разрядный процессор может работать с 16ти разрядными семплами медленнее чем с 32х разрядными.

[moozooh]

Изменения относятся лишь к производительности в каждом конкретном случае.
32х разрядный процессор может работать с 16ти разрядными семплами медленнее чем с 32х разрядными.

Фишка в том, что внутренние вычисления Фубара уже 64-битные. 32 или 16 бит мы можем поставить только на вывод. А вывод — это уже задача саундкарты, а не процессора. Вот что я имел в виду. При этом даунсэмплинг произойдёт в любом случае (32 бита-то мы вообще нигде не выведем, такое разрешение только для преобразований смысл имеет), а это лишние затраты ресурсов. Поэтому быстрее с 32 битами не получится.

[Иван]

А ошибки округления при декодировании зависят от процессора? То есть если я буду декодировать на 32-битном и 64-битном процессорах один и тот же файл, то получу разные результаты, что ли? о_0

Да. :) Но только если будет использована 64х битная программа для декодирования. Тогда она будет оперировать числами формата double, размер которых 2 слова, т.е. 128 бит для 64x, вместо 64 бит для 32x.

А если на выходе 16 бит PCM, то округление до этой длины стирает различия.

[arcman]

moozooh
Я не только Фубар имел в виду - размышлял "вообще".
То что у Фубара внутри знают толко те кто в нём копался, лично мне вообще непонятно где там эти 64 бита в нём используются и зачем.
Драйвер звучки и сама звучка тоже могут много сюрпризов приподнести, поэтому и в плане производительности и в плане кач-ва всегда нужен адекватный экспиремент.

[moozooh]

лично мне вообще непонятно где там эти 64 бита в нём используются и зачем.

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

[arcman]

moozooh
у целых чисел нет ошибок округления.
2/1 -- полюбому 2, хоть ты его 3мя битами закодируешь, хоть 64мя.
1/2 -- полюбому 0.

переполнение при умножении - там да, результат _временно_ можно в регистр удвоенной разрядности сохранить, но не использовать его в таком виде всё время.

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

Так что зачем (и где) там эти 64 бита для меня по прежнему загадка.

[Sunday]

moozooh
у целых чисел нет ошибок округления.
2/1 -- полюбому 2, хоть ты его 3мя битами закодируешь, хоть 64мя.
1/2 -- полюбому 0.

переполнение при умножении - там да, результат _временно_ можно в регистр удвоенной разрядности сохранить, но не использовать его в таком виде всё время.

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

Так что зачем (и где) там эти 64 бита для меня по прежнему загадка.

целочисленых вычислений обычно мало бывает, лосси форматы и большинство DSP используют плавающую точку, PPHS ресемплер в обычном режиме работает с 32х битной точьностью, при включении режима 'Ultra mode' в нём используются вычисления с повышенной точностью (конкретно о битах писалось в FAQ fb2k 0.8.3) так-что где надо там и используются

[arcman]

Sunday
Нормальная плав. точка - это 80битные регистры FPU.
64 - возможно два по 32 программной эмитации (целая и дробные части отдельно)

[D.A.S.]

Вот небольшой опросничек.... По поводу излюбленого пользователями софтварного плеера.


Как видим, лидирующие софтварные плеера, имеют довольно таки, консервативный настрой к OGG Vorbis.

Что конечно тоже сказываеться....

Winamp, WMP, и iTunes лидируют, все эти лидирующие плеера, имеют возможность дефолтно без всяких доп плагинов и прочего граббить CD в Mp3, Winamp и WMP имеют возможность в WMA, Winamp и iTunes в AAC.

iTunes еще и кодировать может в AAC.

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

Вобщем, не хорошо однако... Допустим если бы все эти плеера еще и с OGG Vorbis дружили лучше, то продвижение его только за счет этих плееров могло гораздо дальше зайти...

[arcman]

D.A.S.
Ты чего?
Винамп держит OGG в стандартной поставке, начиная с версии 2.90

[D.A.S.]

D.A.S.
Ты чего?
Винамп держит OGG в стандартной поставке, начиная с версии 2.90

Дак, я о другом совершенно, держит то он держит.... Но уже не раз подчеркивалось, то, что файлы в Ogg Vorbis легче всего найти - это самостоятельно их эти файлы закодировав в Ogg Vorbis.

Я говорил о...

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

И OGG Vorbis там нету, хотя никто не запрещает его там иметь...

И могу сказать одно, это уж никак не на пользу популяризации Vorbis...