Лучший софтовый плеер (обсуждение)

[dhead 1]

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

Стабильная длительность промежутка между семплами необходима всегда и везде, где присутсвует аппаратная обработка цифрового потока, который был или будет звуком.

 

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

 

P.S.

to TRaMeLL

есть подозрение, что разница в звучании даже при битперфектной передаче с разными кабелями теоретически может объясняться накоплением джиттера в цепочке "s/pdif передатчик-> s/pdif интерфейс -> s/pdif приемник-> цап".

vitamir, вы это имели в виду?

[vitamir 3]

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

Нет, неправильно. Побитовой точности недостаточно. Еще необходимо, чтобы остаточный джиттер данных, принятых по каналу S/P DIF, после приемника составлял не более 100....170 пс амплитуды. В реальности может быть больше и именно это может привести к заметным на слух отличиям в звуке при наличии битперфектной передачи цифрового потока.

 

Разумеется, это не означает, что лапши достаточно на все случаи жизни В других условиях затухание сигнала + несогласованность по импедансу + наводки приведут к порче цифровых данных, что приведет к искажениям.

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

 

есть подозрение, что разница в звучании даже при битперфектной передаче с разными кабелями теоретически может объясняться накоплением джиттера в цепочке "s/pdif передатчик-> s/pdif интерфейс -> s/pdif приемник-> цап".

vitamir, вы это имели в виду?

Да, это. И не теоретически, а в суровой реальности.

[TRaMeLL 0]

P.S.

to TRaMeLL

есть подозрение, что разница в звучании даже при битперфектной передаче с разными кабелями теоретически может объясняться накоплением джиттера в цепочке "s/pdif передатчик-> s/pdif интерфейс -> s/pdif приемник-> цап".

Теоретически да, возможно. Но если предположить что ЦАП имеет достаточно эффективное средство подавления джиттера, то главным остается побитовая точность передачи данных.

Нашел пример подобного ЦАП-а: http://overture.org.ua/?p=153

 

И еще одно, в случае использования оптического SPDIF при побитовой передачи данных джиттер даже теоретически не может передаться от передатчика к приемнику (вспоминаем принцип дейсвия оптического передатчика - он может передавать только два крайних состояния горит\не горит и ничего больше).

[dhead 1]

И еще одно, в случае использования оптического SPDIF при побитовой передачи данных джиттер даже

теоретически не может передаться от передатчика к приемнику (вспоминаем принцип дейсвия оптического передатчика - он может передавать только два крайних состояния горит\не горит и ничего больше).

По-моему, это то же самое, что сказать, что с коаксиал-s/pdif не должно быть никаких проблем - "есть сигнал\нет сигнала". А то, что в случае передачи цифры посредством оптического интерфейса в цепочку добавляется двойное преобразование, вносящее собственный джиттер, вы не учли?

Если уж на то пошло, то более правильным способом избавиться от влияния интерфейсного джиттера будет передача данных по асинхронному usb.

[TRaMeLL 0]

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

[dhead 1]

TRaMeLL

ок, еще раз: "А то, что в случае передачи цифры посредством оптического интерфейса в цепочку добавляется двойное преобразование, вносящее собственный джиттер, вы не учли?"

[TRaMeLL 0]

Вы про какое "двойное преобразование" говорите? Первый раз при при преобразовании электрического сигнала в световой и втрой раз при обратном преобразовании чтоли? Я вам только что обьяснял, что принцип накопления джиттера в случае с оптикой не работает. Джиттер приемника накладывается на "чистый" сигнал, а не добавляется к джиттеру в сигнале от передатчика.

 

Или вы считаете, что собственный джиттер оптического приемника равен суммарному джиттеру проходящему через коаксиал или даже больше него?

[dhead 1]

TRaMeLL

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

[vitamir 3]

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

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

В работоспособном интерфейсе (а другого нет смысла рассматривать) интерфейсный джиттер не приводит к искажению данных (нулей и единиц), а приводит к искажению длительностей этих самых нулей и единиц.

А теперь идите изучать матчасть, в частности, процедуру сигма-дельта А/Ц-Ц/А преобразования, может полегчает.

 

Если на пальцах

И пальцы разогните до тех пор, пока матчасть не изучите.

[TRaMeLL 0]

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

[clubnewmen 3 314 2 Тракты]

До свидания. Надеюсь изучения матчасти пойдет на пользу.

[rostian 0]

Всем привет.

Можна чуть возобновить тему?....

Решил попробовать J.River.

Насчет здешних споров по качеству звука - отдельная история...

А обнаружился глючок, может кто чего посоветует....

При проигрывании образов дисков во flac с cue (ИМЕННО образов, отдельные файлы проигрываются нормально) в случайном месте трек обрывается и проигрывается следующий в списке. Пробовал на разных образах разных дисков.

Пробовал на 14 и 16 версиях.

Использую передескретизацию на 192 КГц и вывод ASIO

[Sent 0]

rostian, установите:

 

Смена частоты: Частота источника

Размер потока: Размер потока источника

[rostian 0]

rostian, установите:

 

Смена частоты: Частота источника

Размер потока: Размер потока источника

 

Спасибо.

Я конечно попробую.

Только передескретизация мне нужна.

Так цап лучше работает...

[clubnewmen 3 314 2 Тракты]

Тема про Album player (a player) перенесена сюда

[firevlad 0]

А кто с какими настройками использует Jplay ?

Сам производитель советует использовать Kernel Streaming, а мне кажется что с WASAPI звучит как то получше.

Не очень понял разницу между Beach и River - вернее не услышал, если кто заметил опишите пожалуйста.

[Адам 1 042]

у меня без режима о и h лучше с WASAPI звучит, при их активации лучше с Kernel Streaming, вообще намного лучше звук становится в этих режимах Beach ватно звучит, его нужно использовать на спокойных композициях, я пробовал на думе не втыкает, он для очень размеренных композиций на живых инструментах без напряженной эмоциональной окраски.

[unmen 0]

River и правда как-то настойчивее, нежели Beach.

Что, в принципе, в названиях режимов и отражено (:

 

А Overdrive кто-либо тестил?

[Адам 1 042]

все же jplay нравится больше всех, никто его не подлечил еще?

[vitta77 820]

JPLAY v3.3 released!

Лучший (для меня) софтовый плеер!!!

 

We proudly present JPLAY v3.3 – reaching new levels of sound quality!

What’s New:

 

DirectLink feature: For the first time CD material is guaranteed to work with lowest latency of 1 sample on any PCI or USB audio interface! Simply reduce ‘buffer’ setting to 1 and try it out!

Hi-rez 24/96 & 24/192 material benefits from lower latency as well although depending on pc/driver/audio interface may require 2 or 4 samples buffer setting.

Together with newly optimized sound engine DirectLink makes jplay v3.3 sound even better than v3.2!

 

 

 

What’s Improved:

 

AIFF files ripped with dbPowerAmp containing AccurateRip metadata were not recognized – fixed. Thanks go to Bryan from UK!

24/192 files using more than 3GB filecache did not work – fixed. Thanks go to Francesco from Italy!

Chinese letters in track names should be displayed properly (on Chinese Windows at least) – Thanks go to Exam & Ko from Taiwan!

‘Overdrive’ mode has been integrated into Hibernate and removed from menu (it is still possible to deactivate Overdrive in settings file if needed)

[Адам 1 042]

с buffersize стало что то не очень понятно, лекарства то еще не придумали к нему?

[localhyist 38 14 Тракты]

все же jplay нравится больше всех, никто его не подлечил еще?

У меня почему то этот плейер заикается... Хотя не спорю , играет натуральней фубара. На брту оригинальный виндовс 7 /64.

[______ 999 999]

У меня почему то этот плейер заикается...

"Trial version! Music will sometimes be interrupted"

[localhyist 38 14 Тракты]

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

[localhyist 38 14 Тракты]

Кстати, обратите внимание на новую версию Айтюнса. На лицо очень существенная переработка софта. Звучание у плеера стало реалистичней и получило четко выраженный СиюДюшный характер. Вавки в формате 16/48 звучат на мой взгляд даже лучше чем в фубаре. Характерная айтюновская плосковатость звука практически стала незаметна.