(24-08-2018 12:54)AudioTomCat писал(а):  Как бы не всем хочется переться за 400-1000 км чтобы кому-то доказывать что-то.

Так я готов поехать, если не очень далеко и с предварительным согласованием условий.
https://hi-fi-forum.net/forum/thread-186...pid3893974
Но тогда уже ставочку придется поднять хотя бы до 200-300$
Так, глядишь, поезжу по Украине и наколядую себе на Руарки Excalibur

(24-08-2018 12:38)nem2007 писал(а):  При чтении +30, при записи -30, согласно информации AccurateRip и др.

---

Смещение для записи выставляется по формуле Write Offset = Combined Read/Write Offset – Read Offset
То есть, нужно отнимать от комбинированного значения, а не от смещения чтения, сорри.

(24-08-2018 13:12)zick писал(а):  Смещение для записи выставляется по формуле Write Offset = Combined Read/Write Offset – Read Offset
То есть, нужно отнимать от комбинированного значения, а не от смещения чтения, сорри.

Безусловно я это знаю. Но именно это значение для записи, для Пексторов Премиум (1-2) и есть правильное, я давно это дело вычияслял и еще работала вто время пользовательская база данных смещений на этом сайте _http://eac.h12.ru
Именно я и выставил такое значение.

_https://hydrogenaud.io/index.php/topic,9989.0.html

Цитата:read offset is +30.

I believe the write offset is -30.

_http://eac.yahoogroups.narkive.com/N6jcJ1zX/plexwriter-52-24-52a-plextor-cd-r-px-w52224a-offsets

Цитата:Plex Premium Read Offset = +30 (yes, plus. It's just a notational convention difference)

Plex Premium Write Offset = -30

_https://club.myce.com/t/eac-drive-options-for-plex-premium/67444/4

Цитата:the offset is allways +30 (and for the writer -30)

_http://www.fidelizer-audio.com/introducing-accuratefix-the-way-to-use-accuraterip-correctly/

Да, плекстор в плекстулс смещение сам указывает и для чтения и для записи. Владельцам других приводов придётся рипать, сохранять, записывать с сохранённых вавок..... или не заморачиваться.

Кстати, ни разу не юзал ПлексТулс для записи, даже не знаю, где там смотреть смещение

(24-08-2018 09:49)serapion1984 писал(а):  Ох Вы даете. Постепенно соглашаетесь с одним утверждением, тут же выдумываете новое.
Скиньте видос как Вы копируете с проводника на рабочий стол дорожку номер 4 и у Вас получается на выходе файл формата cdda
(без задействования граббинга, упаковки PCM в WAVE контейнер)

Фига се... Сначала человек утверждает, что CD-DA в отличие от DVD-video нельзя скинуть средствами винды и что именно поэтому его невозможно скопировать на винчестер 1 в 1 вообще.

Когда человека тычешь носом, что настоящий фирменный DVD-video тоже нельзя скопировать средствами винды, и что на самом деле его можно скопировать тоже только с помощью сторонних программ (как и в случае с аудио-CD)...

...тут же начинается какое-то выдумывание и приписывание мне какой-то не относящейся к сути вопроса белиберды.

Хотя суть была элементарно понятна - что невозможность копирования чего-либо с помощью винды вовсе не говорит о невозможности копирования этого "чего-либо" с помощью других программ.

И что на аудио-CD записан обычный компьютерный файл. Без каких-либо чудес.

P.S. Там один ещё насчёт возможности записи аудио-CD с выключением лазера между треками спорил. Тоже похохатывал. Но сразу куда-то слился, узнав о TAO и DAO.

(23-08-2018 22:01)ms142 писал(а):  Это поверхностный принцип работы архиваторов с потерями (типа мр3). Беспотерьные архиваторы (rar, zip и т.д.) четко знают, где ставить 0, а где 1.

Хотелось бы знать откуда они знают. Ведь программе нужно указать: "Здесь поставь 0, а здесь 1". В итоге в архиве должны находиться все 0 и 1, и ещё толкователь "где их расставлять". Это получается по весу больше чем до сжатия.

(24-08-2018 21:08)vovanrecords писал(а):  Хотелось бы знать откуда они знают. Ведь программе нужно указать: "Здесь поставь 0, а здесь 1". В итоге в архиве должны находиться все 0 и 1, и ещё толкователь "где их расставлять". Это получается по весу больше чем до сжатия.

_http://1001file.ru/article/teoriya-kompyuternoy-gramotnosti/rabota-archivatora.html

Цитата:Данный метод подразумевает использование словаря из последовательностей данных, или слов. Причем в качестве словаря служит сам исходный блок данных. Для показа всего вышесказанного на примере, можно прибегнуть к следующему примеру: имеем двоичный фрагмент файла — 10111011101110110011. Как видим в данном примере четыре раза повторяется комбинация 1011, именно ее архиватор записывает один раз, а после проставляет кратность повторения.

И еще немного инфы:

_http://www.nestor.minsk.by/kg/1998/43/kg84316.htm

_https://habr.com/post/231177/

_http://log.toeoda.com/Compression/Archivers/archivers.htm

(24-08-2018 21:08)vovanrecords писал(а):  Хотелось бы знать откуда они знают. Ведь программе нужно указать: "Здесь поставь 0, а здесь 1". В итоге в архиве должны находиться все 0 и 1, и ещё толкователь "где их расставлять". Это получается по весу больше чем до сжатия.

А вот за "хотелось бы знать" создателям этих программ бешеные деньги и платят.
Потому что хочется всем, а знают - единицы.

Можно описать несколько последовательностей повторяющихся битов всего одной. И указать - где и сколько раз её следует при распаковке повторить. А одна такая последовательность с указанием занимает меньше места, чем 20 последовательностей.
Как-то так.

P.S. Упс, nem2007 уже раньше написал и даже с примерами.)

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

Добавлю о смещении, это на качество звука не влияет абсолютно.

Конечно. Но им не доказать.

Можно сколько угодно надувать щёки и говорить что разницы в звучании сжатого-несжатого файлов нету, но она есть. И причина здесь не в битовой неидентичности

(24-08-2018 22:25)VNV73 писал(а):  Можно сколько угодно надувать щёки и говорить что разницы в звучании сжатого-несжатого файлов нету, но она есть. И причина здесь не в битовой неидентичности

Между сжатым и не сжатым - да, есть (но не каждый ее еще услышит).
А между не сжатым, а затем сжатым и снова расжатым - нету и быть не может.

(24-08-2018 22:25)VNV73 писал(а):  Можно сколько угодно надувать щёки и говорить что разницы в звучании сжатого-несжатого файлов нету, но она есть. И причина здесь не в битовой неидентичности

Аминь.
Там примерно те же аргументы.

---

(24-08-2018 22:42)nem2007 писал(а):  Между сжатым и не сжатым - да, есть (но не каждый ее еще услышит).

Это как? ? ? Если любой флак/ape (и т.д.) сначала переводится в PCM, а потом идёт в цап, как обычный PCM.

(24-08-2018 22:45)Abizian писал(а):  Это как? ? ? Если любой флак/ape (и т.д.) сначала переводится в PCM, а потом идёт в цап, как обычный PCM.

Я имел ввиду "сжатый" - это MP3 и ему подобные.
А про APE/FLAC тут столько легенд ходит, что просто ужас..
Кто-то считает, что когда FLAC попадает в "буфер" и из него затем воспроизводится - это зло.
Надо мол только напрямую с WAV

Abizian, в год когда изобрели аудио СД, расскажите как можно было скопировать трек номер 4?))
Аудио риппинг это извлечение цифровой информации в виде PCM cигнала с последующей упаковкой в контейнер и как следствие в файл. Сделать такое появилось возможность гораздо позже выхода Аудио-СД.
Оговорюсь специально для Вас. Я не спорю, что PCM получится идетничный с тем, который записанный на диске.

Только я уже больше 40 страниц не могу понять какое отношение идентичность цифровой информации имеет к звуку?
Звук разный совершенно по другим причинам.

(24-08-2018 22:56)nem2007 писал(а):  Кто-то считает, что когда FLAC попадает в "буфер" и из него затем воспроизводится - это зло.
Надо мол только напрямую с WAV

Нагрузка на проц с Flac и количество операций выше - сначала идёт распаковка в буфер и потом уже скармливание аудио девайсу.

(24-08-2018 23:14)adsh писал(а):  Нагрузка на проц с Flac и количество операций выше - сначала идёт распаковка в буфер и потом уже скармливание аудио девайсу.

Это я понимаю, но вот для многих аудиофилов - это не аргумент. Звучит хуже, хоть тресни!

(24-08-2018 21:21)Abizian писал(а):  Вера никогда с логикой не дружит...

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

(24-08-2018 23:14)adsh писал(а):  Нагрузка на проц с Flac и количество операций выше - сначала идёт распаковка в буфер и потом уже скармливание аудио девайсу.

Ерунда, есть такая штука - "аппаратная поддержка". Суть: попробуйте PII воcпроизвести DVD-video. Сможете? А PIV не будет загружен даже на 5%, хотя он не в 20 раз мощнее.
Но даже при программной поддержке, когда процессор многократно мощнее необходимого для нужной задачи - нагрузка может быть малозаметной. Суть - раньше для win95 нужен был максимально мощный проц. А щас её работу можно эмулировать самым слабым из процессоров внутри абсолютно другой операционной системы - и проц этого даже не заметит, занимаясь, например, кодированием в H265 в то же самое время.

P.S. CD-проигрывателю во время воспроизведения CD ещё кучу дел приходится делать - следить за дорожкой и регулировать положение головки, разбираться с кодом Рида-Соломона, восстанавливать сигнал по теореме Котельникова, отправлять его помимо цапа на цифровой выход, циферки всякие на дисплее показывать и т.д. Но у него проц имеет аппаратную поддержку для этого. Т.ч. ему это - по барабану.
Также и с флаком/апе и т.д. Никаких проблем. Нынче самый хилый проц делает это в сотни раз быстрее реального времени даже без аппаратной поддержки.

---

(24-08-2018 23:27)smakerbus писал(а):  мир не цифровой, а аналоговый

Как знать... как знать. "Матрица", "Тринадцатый этаж"... Как бы не оказались мы компьютерной эмуляцией.