Apollo 37zv vs Foobar 0.9 vs Winamp 5.21

Список разделов Ogg Vorbis Софт

Описание: Программное обеспечение с поддержкой свободных форматов

Сообщение #106 moozooh » 10.06.2006, 12:44

arcman писал(а):Не всё так однозначно с битностью данных.
32х разрядным процессорам проще работать именно с 32х разрядными данными, переход на 16ти разрядные данные может не дать ускорения или даже замедлить работу.
Использовать 24х разрядное представление, с точки зрения производительности, может оказаться совсем бесполезным.
А не могли бы Вы мне объяснить, каким образом разрядность процессора связана с количеством бит, отводимых на сэмпл (если мы говорим о целочисленных форматах), или с точностью вычислений чисел с плавающей точкой? :roll:
moozooh
Сторонник
С нами: 13 лет 4 месяца

Сообщение #107 Иван » 12.06.2006, 15:35

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

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

А точность выч с плав точкой зависит напрямую, потому что ошибки округления в процессе расчета становятся меньше, и финал получается точнее, чем для процессора с меньшей длиной слова.
Иван
Увлечённый
Аватара
Откуда: г. Королев Моск Обл
С нами: 13 лет 5 месяцев

Сообщение #108 moozooh » 13.06.2006, 03:11

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

Иван писал(а):А точность выч с плав точкой зависит напрямую, потому что ошибки округления в процессе расчета становятся меньше, и финал получается точнее, чем для процессора с меньшей длиной слова.
А ошибки округления при декодировании зависят от процессора? То есть если я буду декодировать на 32-битном и 64-битном процессорах один и тот же файл, то получу разные результаты, что ли? о_0
moozooh
Сторонник
С нами: 13 лет 4 месяца

Сообщение #109 Sunday » 13.06.2006, 05:46

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

Сообщение #110 arcman » 13.06.2006, 14:39

moozooh
А не могли бы Вы мне объяснить, каким образом разрядность процессора связана с количеством бит, отводимых на сэмпл (если мы говорим о целочисленных форматах), или с точностью вычислений чисел с плавающей точкой?
Никак.
Кач-во не претерпит изменений при адекватной реализации.
Изменения относятся лишь к производительности в каждом конкретном случае.
32х разрядный процессор может работать с 16ти разрядными семплами медленнее чем с 32х разрядными.
arcman
Последователь
Откуда: Kazan
С нами: 13 лет 5 месяцев

Сообщение #111 moozooh » 13.06.2006, 17:19

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

Сообщение #112 Иван » 13.06.2006, 17:48

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

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

А если на выходе 16 бит PCM, то округление до этой длины стирает различия.
Иван
Увлечённый
Аватара
Откуда: г. Королев Моск Обл
С нами: 13 лет 5 месяцев

Сообщение #113 arcman » 13.06.2006, 20:17

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

Сообщение #114 moozooh » 13.06.2006, 20:34

arcman писал(а):лично мне вообще непонятно где там эти 64 бита в нём используются и зачем.
На всех звеньях цепи между декодированием и выводом, насколько я понимаю. Предположительно, как раз для того, чтобы ошибок округления при наложении DSP и дизеринге не происходило.
moozooh
Сторонник
С нами: 13 лет 4 месяца

Сообщение #115 arcman » 14.06.2006, 11:53

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

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

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

Так что зачем (и где) там эти 64 бита для меня по прежнему загадка.
arcman
Последователь
Откуда: Kazan
С нами: 13 лет 5 месяцев

Сообщение #116 Sunday » 14.06.2006, 19:35

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

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

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

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

Сообщение #117 arcman » 15.06.2006, 12:03

Sunday
Нормальная плав. точка - это 80битные регистры FPU.
64 - возможно два по 32 программной эмитации (целая и дробные части отдельно)
arcman
Последователь
Откуда: Kazan
С нами: 13 лет 5 месяцев

Сообщение #118 D.A.S. » 24.06.2006, 16:17

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

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

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

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

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

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

Вобщем, не хорошо однако... Допустим если бы все эти плеера еще и с OGG Vorbis дружили лучше, то продвижение его только за счет этих плееров могло гораздо дальше зайти...
D.A.S. M
Сторонник
Аватара
Откуда: Одесса
С нами: 13 лет 5 месяцев

Сообщение #119 arcman » 24.06.2006, 18:41

D.A.S.
Ты чего?
Винамп держит OGG в стандартной поставке, начиная с версии 2.90
arcman
Последователь
Откуда: Kazan
С нами: 13 лет 5 месяцев

Сообщение #120 D.A.S. » 24.06.2006, 19:34

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

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

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

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

И могу сказать одно, это уж никак не на пользу популяризации Vorbis...
D.A.S. M
Сторонник
Аватара
Откуда: Одесса
С нами: 13 лет 5 месяцев

Пред.След.

Вернуться в Софт

Интересные статьи

cron