Bitperfect? А если проверить? Или все аудио-плееры звучат одинаково.

Это не так. Вы написали “Этот тест полная профанация.” При этом базовый вопрос теста никак не связан с содержанием ваших последующих комментариев.

Еще раз. “Битперфект” это вопрос корректности передачи битов, которые были в исходном файле. Тушенка из банки доехала до адресата без изменений и добавок, в этой, самой очевидной части плеер выполнил задачу честно.
Если есть, что добавить о том какие искажения (намеренно или ненамеренно), именно аудио-плеер может внести в поток, чтобы скорректировать тезис «все аудио-плееры играют одинаково» - напишите.

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

И здесь еще раз повторюсь. В целом вопрос здесь - офтопик, если есть что к аудио-плеерам явно применимое - сообщите.
В целом же по этому вопросу - асинхронный буфер на то и асинхронный, чтобы развязаться от остального тракта. Как это может быть реализовано в конкретном ЦАПе - вопрос второй и к теме ветки отношения не имеющий.

Ок. Если целью исследования был чисто академический интерес по количеству переданных бит, то да. Практически все современные плееры битперфектны. Тут нет ничего удивительного. Поскольку передавать без изменений проще, чем добавлять что то от себя.

В Ваших итоговых выводах присутствует фраза «плееры играют». В контексте плееров, для меня это равнозначно слову звучат.
Именно это сбило с толку и по вашему мнению, я начал оффтопить.

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

Что впрочем не мешает субъективно насладиться великолепием того же roon или строгостью foobar ))

Пианист сыграл все ноты - нажал на нужные клавиши, просто немного сбился с ритма …

Вообще тайминг - просто ключевой вопрос DA-преобразования, потому что время в цифровом потоке кодируется абсолютно аналогово. Биты уже давно научились доставлять без потерь.

4 лайка

Не про пианиста в этой ветке. А про подавальщика нот ) Подавальщик нот (аудиоплеер) открыл коробку с нотами, какие запросил слушатель, по очереди берет нужный листочек ничего от себя не дописывая и передает пианисту (ЦАПу). Ну а пианист уж уж нажимает клавиши как умеет - сбиваясь с ритма или нет.

Ну и про тайминг еще раз призову обсуждение вести применительно к конкретным конструкциям ЦАПов, а не как некий вселенский ужас-ужас. Продолжая аналогию, многие пианисты способны принять (в буфер) целый том нот и имеют возможность не зависеть от подавальщика нот.

1 лайк

Я точно не знаю всех конструкций ЦАПов.

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

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

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

Разница в производимом эффекте)

Слепыми тестами я редко балуюсь, есть другой вариант - меняешь что-то в системе (не говоря супруге) и уходишь на работу. Если не показалось и разница реально есть, то вечером она спрашивает что я опять купил :grin:

2 лайка

Продолжить пообщаться в этом направлении свербит, но здесь воздержусь, м.б. в отдельной ветке. Только еще раз констатирую - к аудио-плеерам затронутая тематика не относится, вопрос на стороне ЦАП.

В контексте последних обсуждений timeperfect можно выполнить простой эксперимент - подменить частоту в тестовом файле, не выполняя фактического пересчета следующей командой :
sox -r 176.4k input.wav output.wav
Сами биты при этом не затрагиваются (банальная правка заголовка), но при воспроизведении все частоты кратно увеличатся. Любопытно, пройдет ли проверку тестовый файл после подобного вмешательства?

Понятно. Т.е. сравнение не систематизированное по какой-то методике слепое, а скажем так “эмоциональное слепое” имелось в виду. Вопросы снимаю. Как серьезную доказательную базу подтверждения различий принять сложно, при всем уважении ))

1 лайк

А в чем задача эксперимента, что проверяем?

Не совсем так, мне видится что фапч обычно так устроены, что входящий сигнал заметно влияет.

Появится ли сообщение об ошибке при грубейшем нарушении скорости воспроизведения.

1 лайк

Один подавальщик подаёт идеально вовремя, так, что пианист начинает новый лист аккурат тогда, когда уже прочёл предыдущий. Другой суетится и то опаздывает, то пихает раньше времени. С первым подавальщиком пианисту легче, он играет не отвлекаясь на листы и реализует свои умения полностью. Со вторым - сложнее, суета эта отвлекает, заставляет ждать или наоборот торопиться. Логично предположить, что в этом случае у пианиста получится не лучшее выступление.

1 лайк

А что проверяем то? Что докажем или опровергнем этим экспериментом?

Если четырехкратное увеличение скорости воспроизведения тестового трека (44,1 -> 176.4kHz) не приведет к ошибке, констатируем, что успешное прохождение теста на bitperfect является необходимым, но недостаточным условием для проверки программых проигрывателей на “идентичность выходного потока”.
Частоту, кстати, можно выставить произвольно:

−r, −−rate RATE[k]
Gives the sample rate in Hz (or kHz if appended with ‘k’) of the file.

For an input file, the most common use for this option is to inform SoX of the sample rate of a ‘raw’ (‘headerless’) audio file (see the examples in −b and −c above). Occasionally it may be useful to use this option with a ‘headered’ file, in order to override the (presumably incorrect) value in the header - note that this is only supported with certain file types. For example, if audio was recorded with a sample-rate of say 48k from a source that played back a little, say 1.5%, too slowly, then

sox −r 48720 input.wav output.wav

effectively corrects the speed by changing only the file header.

Я так понимаю мы до более сложной схемы договорились. Что у современного пианиста как правило есть том с нотами, с запасами, который подавальщик успевает успевает пополнять. Но есть подозрение что большинство пианистов сэкономили на обучении и при чтении нот постоянно подглядывают на подавальщика, с каким ритмом он работает. И в такой аналогии подавальщик уже не аудиоплеер, а конструкция из аудиоплеера+драйвера+железа в компьютере и ЦАПе. И выглядит логичным пианисту научиться читать из буфера c нужным ему ритмом. Насколько эти умения имеются - вопрос открытый.

Так и не понял, как это докажет написанное выше. Причем тут вообще “проверка программых проигрывателей на “идентичность выходного потока””?

И если подсовываем на вход файл с искаженным заголовком вместо предназначенного для тестирования с учетом недокументированности того как ЦАП должен реагировать на подобное, можно делать выводы только о реализации функции контроля “bitperfect” в конкретном ЦАПе на нештатных входных данных.

1 лайк

Как раз в этом и соль - биты как таковые остаются интактными, меняется лишь время их прибытия в плату приемника.

Могу только еще раз повторить написанное выше. Ничего применяя нештатный файл для штатной функции невозможно ни подтвердить ни опровергнуть. Т.к. невозможно отличить корректную работу на расширенных параметрах от некорректной работы на искаженных параметрах.

1 лайк