Ребята, - все честно!
Действительно был сгенерирован файл, переконвертирован первым попавшимся под руку конвертором, и им-же обратно.
(переименование тут не причем).
И Гаруспик был прав, когда предположил, что дело в изменении разрядности.
Это аксакалы знают, какими программами пользоваться, освоили чуть ли не до программного кода все настройки....
Давно обратил внимание, что большинство контента в сети - отвратного качества, но в то же время попадаются фирменные файлы, сделанные так сказать для презентаций, - они сделаны весьма хорошо. Да и на студиях как то же мастерят с весьма хорошим качеством записи и вовсю пользуются изменением разрядности.
Вообщем пока выводы такие:
1. лослеские кодеки действительно не изменяют сигнал при условии грамотного обращения.
2. Нужно весьма осторожно относится к изменению разрядности. (если контент в СД формате - незачем его переводить в 24\96, если это не студия, где используется совсем другое оборудование, нежели домашний комп).
Так что разбираемся дальше.

(21-02-2013 17:05)Вячслав_М писал(а):  2. Нужно весьма осторожно относится к изменению разрядности. (если контент в СД формате - незачем его переводить в 24\96, если это не студия, где используется совсем другое оборудование, нежели домашний комп).
Так что разбираемся дальше.

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

(21-02-2013 17:22)cunnilinux писал(а):  

(21-02-2013 17:05)Вячслав_М писал(а):  2. Нужно весьма осторожно относится к изменению разрядности. (если контент в СД формате - незачем его переводить в 24\96, если это не студия, где используется совсем другое оборудование, нежели домашний комп).
Так что разбираемся дальше.

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

Придется изменить этим правилам переводя sacd - flac

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

(21-02-2013 17:35)cunnilinux писал(а):  зачем?! правильнее обзавестись звуковой картой, которая умеет без проблем играть аудиопоток в высоких разрешениях и/или во много каналов.

Sacd - проигрывателем, так будет точнее.

Зачем переводить?
Правильней иметь устройства для воспроизведения и того, и этого.

(21-02-2013 17:38)Simuran писал(а):  Зачем переводить?
Правильней иметь устройства для воспроизведения и того, и этого.

И нет проблем Вам там хорошо ...

ааааа блин, позор мне. я и забыл, что SACD — не PCM ни разу.
тогда ой.

(21-02-2013 17:38)Simuran писал(а):  Зачем переводить?
Правильней иметь устройства для воспроизведения и того, и этого.

И самое правильное не сравнивать потом результаты из этих устройств, ибо реализация их разная!

(21-02-2013 16:58)cunnilinux писал(а):  у меня всё по-честному, в командной строке

А у меня Foobar на ура справляется что с аре, что с flac-ом.

---

(21-02-2013 17:05)Вячслав_М писал(а):  2. Нужно весьма осторожно относится к изменению разрядности. (если контент в СД формате - незачем его переводить в 24\96

Простите, Вы попросту сделали ресемплинг-т.е. 16\44,1 загнали в 24\96. Не просто сграбили СД в 16\44,1. И кто-то удивляется, что на выходе не то?

---

(21-02-2013 17:35)cunnilinux писал(а):  умеет без проблем играть аудиопоток в высоких разрешениях

Хм-а разве еще есть ЗК, которые не умеют работать мин. с 24\96?

http://hiend-audio.pro/showthread.php/12...-не-влияет

FLAC, APE и другие форматы сжатия без потерь. Эти форматы рассчитаны на то, что если произвести распаковку сжатых данных, то полученные данные должны совпадать с исходными бит в бит. Внутри каждого сжатого файла находится информация о формате исходного файла, например 44/16 или 96/24 и распаковка ведется до этого формата. Расчеты при распаковке ведутся с большим разрешением, чем формат выходных данных и распаковка на разных программах и процессорах может приводить к разным незначащим хвостикам данных, например то, что начинается с 17-го бита для файла 44/16. Если использовать оригинальную программу распаковки, то результат однозначен и предсказуем. Однако, если работает плагин и распакованные данные не складываются на диск, то возможна ситуация, что, например тот же Foobar, заказыввает у плагина данные в формате 24 или 32 бита, а исходные данные были в формате 16 бит. В этом случае оставшиеся биты получатся на усмотрение плагина и у разных плагинов, плееров, на разных процессорах эти "незначащие" данные могут быть разные. По этой причине, распаковка "на лету" может приводить к разным результатам, несмотря на проигрывание файлов в формате "без потерь". И действительно, та часть данных, что была в исходном файле, не теряется, но вот додуманные хвостики могут отличаться.(С) Тут непризнанные гении били себя пяткой в грудь,что такого не может быть!

(21-02-2013 20:10)AlexR2 писал(а):  Простите, Вы попросту сделали ресемплинг-т.е. 16\44,1 загнали в 24\96. Не просто сграбили СД в 16\44,1. И кто-то удивляется, что на выходе не то?

Нет. Файл был сгенерирован в 16\44, а конвертер умел только в 16\48. Ну и обратно перевод осуществился в 16\44.

Я там писал о разрядности, но это также касается и частоты дискретизации. Проверил и то и другое.

Это также не отменяет прежних выводов, как:
- такое ресемплирование будет мало заметно в системах с ЦФхХХХ.
А если ЦАП умеет выбирать вид фильтра, то разница будет драматически заметна.

(22-02-2013 01:11)petr.solo1223 писал(а):  но вот додуманные хвостики могут отличаться.(С) Тут непризнанные гении били себя пяткой в грудь,что такого не может быть!

Ребята, всегда читайте внимательно текст полностью и обращайте внимание не на то, на что хочется обратить внимание, а на то что нужно. Цитирую:

Цитата:Если использовать оригинальную программу распаковки, то результат однозначен и предсказуем. Однако, если работает плагин и распакованные данные не складываются на диск, то возможна ситуация, что, например тот же Foobar, заказыввает у плагина данные в формате 24 или 32 бита, а исходные данные были в формате 16 бит.

Родной программой для упаковки\распаковки WAV файлов, есть Flac Frontend.
Фубар может использовать как внешние кодировщики, так и свои собственные. Собственные ничем не отличающиеся от официальных используются в оф.версии , остальные сборки надо проверять. Но все это ерунда по сравнению с тем , что вы сами ничего не услышите, после той плавающей запятой, поэтому не надо строить комедию.
Все небыло бы так смешно, если бы вы сами что то пробовали делать, в том числе и выводы, вместо того что бы читать всевозможные форумы. Человек написал предположение, догадку, не подтвержденную фактами. Хотя в теории, с математической точки зрения все так и выглядит, но спросите у него, слышит ли он то что написал или хотя бы видит разницу в той же самой контрольной сумме?
До сих пор утверждаю: Разницы до и после кодирования - НЕТ!
Единственным исключением является уровень сжатия, влияющий своей степенью сжатия на загрузку процессора ц. плеера. Если нет слышимых артефактов - все в порядке.

(22-02-2013 01:18)Вячслав_М писал(а):  

(21-02-2013 20:10)AlexR2 писал(а):  Простите, Вы попросту сделали ресемплинг-т.е. 16\44,1 загнали в 24\96. Не просто сграбили СД в 16\44,1. И кто-то удивляется, что на выходе не то?

Нет. Файл был сгенерирован в 16\44, а конвертер умел только в 16\48. Ну и обратно перевод осуществился в 16\44.

Я там писал о разрядности, но это также касается и частоты дискретизации. Проверил и то и другое.

Это также не отменяет прежних выводов, как:
- такое ресемплирование будет мало заметно в системах с ЦФхХХХ.
А если ЦАП умеет выбирать вид фильтра, то разница будет драматически заметна.

И все-таки из спортивного интереса: есть возможность выложить спектр исходного файла?

(22-02-2013 02:10)smirnofb писал(а):  

Цитата:Если использовать оригинальную программу распаковки, то результат однозначен и предсказуем. Однако, если работает плагин и распакованные данные не складываются на диск, то возможна ситуация, что, например тот же Foobar, заказыввает у плагина данные в формате 24 или 32 бита, а исходные данные были в формате 16 бит.

Родной программой для упаковки\распаковки WAV файлов, есть Flac Frontend.
Фубар может использовать как внешние кодировщики, так и свои собственные. Собственные ничем не отличающиеся от официальных используются в оф.версии , остальные сборки надо проверять.

Спасибо за ссылку! Будем дальше копать!

Блин, ну просто умиляет иногда поспешность выводов!! Берём исходник 16/44,1 непонятно какой прогой апсемплим до 24/96 или 24/192 ... и делаем удивлённое лицо "Воно нэ так грае!" Если исходный файл 16/44,1 то и манипуляции по сжатию и распаковке должны производится без изменений как разрядности так и частоты дискретизации! А если уж ОВЕРСЕМПЛИТЬ, то нужно делать с МАКСИМАЛЬНОЙ частотой более 300 кГц, тогда манипуляции с ресемплингом имееют практический смысл - сигнал половинной от дискретизации частоты больше похож на синус а не на ту "расчёску" что нарисовали на вложенном графике.

Теперь следующее. Соблюдаем чистоту эксперимента. А именно, берём свой муз-ПК, хороший компакт-диск и 5 хороших болванок. Метим болванки 1,2,3,,,5. С диска делаем копию на болванку №1, потом, с болванки №1 копируем на болванку №2 ... с №2 на №3 ... и ещё ПРАВИЛЬНО НАСТРОЕННЫМ ЕАСом извлекаем WAV и прогой Flac Frontend делаем FLAC. В итоге имеем :
1) Оригинальный диск
2) 5 копий с копий
3) Вавку
4) FLAC
Следующее - все эти экземпляры проигрываем исключительно на этом же муз-ПК. Слушаем, сравниваем, меряем... делаем выводы, отписываемся.

Почему сравнение болваней и КД на КД-плеере будет не корректно и сравнение КД и ПК тоже некорректно объяснять, думаю, никому не надо.

(22-02-2013 09:15)ms142 писал(а):  И все-таки из спортивного интереса: есть возможность выложить спектр исходного файла?

Смысла выкладывать его нет - это просто меандр на 1 кГц, по уровню -3дБ.
Другой сложный сигнал, который сгенерировал и его анализ показал, что достаточно все таки меандра.
Кстати это хороший тестовый сигнал и для источника (на осциллографе видно все "бяки" в зависимости от реализации), и для усилителя и особенно для АС (это вообще высший пилотаж получить хоть нечто напоминающее).
И это также хороший тест для всяких кодировщиков и пр. программ.
Я просто показал, что получится, если подойти к этому на уровне простого пользователя.

(22-02-2013 17:18)Вячслав_М писал(а):  

(22-02-2013 09:15)ms142 писал(а):  И все-таки из спортивного интереса: есть возможность выложить спектр исходного файла?

Смысла выкладывать его нет - это просто меандр на 1 кГц, по уровню -3дБ.
Другой сложный сигнал, который сгенерировал и его анализ показал, что достаточно все таки меандра.
Кстати это хороший тестовый сигнал и для источника (на осциллографе видно все "бяки" в зависимости от реализации), и для усилителя и особенно для АС (это вообще высший пилотаж получить хоть нечто напоминающее).
И это также хороший тест для всяких кодировщиков и пр. программ.
Я просто показал, что получится, если подойти к этому на уровне простого пользователя.

Ой есть смысл, таки посмотрите спектр...
Во-первых - там пачки импульсов. Во-вторых МЕАНДР, а не синус...
И спетр там должен быть очень широкий.

(22-02-2013 19:22)ms142 писал(а):  И спетр там должен быть очень широкий.

Гармонический спектр имеете ввиду?