Количество ступеней регулировки громкости.

[Darth Malkav]

Если аналоговым способом уменьшать громкость - глубина идёт туда же. Вы не сможете слышать тихие звуки в композиции. Чистая физика.

Зависит от качества ЦАПа. Тихие звуки при высокой чувствительности совсем не тихие.

Так это справедливо для любой битности. Разве нет?

Если криво реализовать, то да. Например, громкость регулировать в момент декодинга или процессинга. Если вывод 24-битный, то у вас есть хедрум в 48 децибел. Можно убавить звук до 4% (не минус 4%!) без потерь.

[Artem]

Например, громкость регулировать в момент декодинга или процессинга. Если вывод 24-битный, то у вас есть хедрум в 48 децибел.

Да, запас будет больше, но разве проблема исчезнет? 🤦‍♂️

[Darth Malkav]

Да, запас будет больше, но разве проблема исчезнет? 🤦‍♂️

Возьмём, к примеру, Винду. Вот так выглядит громкость на 25% у Foobar и AIMP. Foobar управляет громкостью через микшер, AIMP через себя. Исчезает проблема или нет, лучше записать и измерить. Записать цифровой сигнал на выходе и сжать его в лосслесс. У малой битности битрейт будет значительно ниже.

[Artem]

Вот так выглядит громкость на 25% у Foobar и AIMP

И? Какой вывод тут нужно сделать? Кроме того, что фубар регулирует через систему, а AIMP - через себя?

У малой битности битрейт будет значительно ниже.

Что логично, т.к. там банально меньше данных (меньше битность) =) Это отнюдь не означает, что сжатие лучше исключительно из-за потерь на громкости.

[Darth Malkav]

И? Какой вывод тут нужно сделать? Кроме того, что фубар регулирует через систему, а AIMP - через себя?

Что логично, т.к. там банально меньше данных (меньше битность) =) Это отнюдь не означает, что сжатие лучше исключительно из-за потерь на громкости.

Насколько могу судить, виндовый АИМП производит все манипуляции со звуком, переведя его в формат 32бит с плавающей точкой, затем всё конвертируется в формат звуковой карты. То есть 16 битный контент на 24 битном выводе не будет терять информацию за исключением процессов квантования. Насчёт андроидовского не уверен, да и девайсы на андроиде имеют в основном 16-битный вывод.

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

[Artem]

уменьшаем громкость песни (теряем информацию) сохраняем, загружаем, увеличиваем громкость песни к изначальному уровню, сохраняем

Так я и говорю, что это справедливо для любой битности? Разве нет

битрейт при сжатии отличается в разы

Ну не в разы.

[Darth Malkav]

Так я и говорю, что это справедливо для любой битности? Разве нет

Ну не в разы.

Имеем изображение 1920х1080. Имеем монитор 1920х1080. Если уменьшаем изображение, чтобы оно было не на весь монитор, то оно будет, допустим, 1280х720, то есть потеря информации. Если у нас изображение 1920х1080 на мониторе 3840х2160, то мы его можем развернуть так, чтобы оно было меньше экрана, но не меньше себя, Например, 2560х1440.

В 2 раза удавалось.

[Soolo]

К чему эта полемика в этой теме?
Не регулировать громкость вообще?
Или что?

[Artem]

Имеем изображение 1920х1080. Имеем монитор 1920х1080. Если уменьшаем изображение, чтобы оно было не на весь монитор, то оно будет, допустим, 1280х720, то есть потеря информации. Если у нас изображение 1920х1080 на мониторе 3840х2160, то мы его можем развернуть так, чтобы оно было меньше экрана, но не меньше себя, Например, 2560х1440.

Некорректно сравниваете, вот и некорректный результат. Чем выше разрешение (битность), тем меньше ошибок округления при изменении громкости. Однако полностью ошибку округления вы не уберете =) Даже у 32 с плавающей запятой есть ограничения.

[AKhod]

  обсудили все на свете, кроме количества ступеней.