Точное копирование Audio CD

Всех их надо собирать из исходников.

А чем сама консольная утилита cdparanoia не угодила? Она есть в репах.

Но все это только для себя, на трекерах допускается только EAC

Просто напиши лог сам, делов-то.

Rubyripper ничуть не хуже EAC
https://github.com/bleskodev/rubyripper#Secure-rip-method
Используй его, все остальное — проблемы форума.

А чем сама консольная утилита cdparanoia не угодила?

Слишком много приходится делать руками (это не весь список, еще надо получить теги с freedb, переименовать файлы, проверить хэш по accuraterip). Можно было бы, конечно, составить скрипт. А если какой-то сбойный участок? cdparanoia не разбивает на участки, тут только спец. утилиты нужны или рипать один диск десятки раз, пока доверительная статистика хэшей не наберется.

Просто напиши лог сам, делов-то.

Откуда я возьму данные и достоверную подпись лога?

Rubyripper используй его

Rubyripper есть только в репозиториях Mageia, надо попробовать Live (из актуальных дистров, а так еще deb multimedia для Debian 7 и ppa для Ubuntu 13.10). Из исходников у меня 0.7 собрался, но при запуске ошибка. Еще ставил пакет от Debian7/8 в Ubuntu 16.04 (пришлось перепаковать, изменив фиксированную зависимость Ruby1.9.1 и там в убунте еще ruby-gtk2 по другому называется). Запустилось, диск открывает, теги с freedb подтягивает, но при попытке рипа падает в сегфолт.
0.6.2 не работает с Ruby>=2.5. В Ubuntu 16.04 2.3, а в 18.04 уже 2.5. 0.7 должна работать.

У меня есть один Audio CD с DRM Cactus Data Shield (технически это не Red Book Audio CD, но это музыка и он так продавался, на обложке предупреждение о DRM). Там искаженная TOC и битые сектора в специальных местах. Помню EAC изрядно помучился, пока копировал, но скопировал таки, хотя одну ошибку допустил. Ранее этот диск другие люди грабили с щелчками (ходил mp3 такой). Надо будет использовать этот CD как стресс тест.

Rubyripper ничуть не хуже EAC

Хуже. Он не умеет сверяться с AccurateRip. Буду пробовать Whipper.

Он не умеет сверяться с AccurateRip

Один человек рассказывал, что даже при успешном копировании в EAC (test+copy) один трек не проходил по базе. Ему посоветовали попробовать на другом приводе и тогда тест прошел. Еще оборудование влиять может. Так что без сверки никуда.

Откуда я возьму данные и достоверную подпись лога?

Данные сам напиши, crc файлов можно подсчитать, хотя сомневаюсь что их кто-то будет сверять. А подпись https://github.com/puddly/eac_logsigner

Слишком много приходится делать руками

Юзай abcde - http://www.andrews-corner.org/linux/abcde/index.html

на трекерах допускается только EAC (Windows, Wine) и XLD (OS X)

Сектанты, ёпт.

Да правила эти уже в печенках. Лет 5-10 назад делал раздачи: качал зарубежные dvd, добавлял рус. звук+сабы и перемуксивал в Muxman. Всё. Потом ввели требования, что нужно блин dvd меню. А это уже на порядок хитрее и я забил.
То ли дело на некоторых сайтах можно даже в облака заливать - гарантированно скачается. Лучше хоть что-то, чем ничего. Я бы много чем мог бы поделиться, да пока все оформишь, потом единственным сидом останешься, комп все время будет пахать, а в комментах контент грязью обольют кто палец о палец не ударил. А ведь релизеры тратят деньги, время, силы...

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

Проклятые проги, все валятся с ошибками. Хоть из ppa, хоть из исходников. Поставлю EAC в дуалбутную винду. А потом еще удивляются почему Linux не поддерживают.

Поставлю EAC в дуалбутную винду. А потом еще удивляются почему Linux не поддерживают.

Ты такой смешной.

Поставлю EAC в дуалбутную винду

Лучше иди клизму себе поставь - полезней будет.

Audio CD с Cactus
стресс тест

Результат в K3B (режим паранойи 3) побитово совпадает с EAC'овским рипом, который у меня давно лежит, к тому же порезанный на треки. Правда я проверил первую песню только.

Кстати, K3B кодирует во FLAC, внезапно только если пакет flac установлен, но в зависимостях он не числится, ох уж эти мейнтейнеры. Хотя из кдешного софта K3B действительно работает в отличии от Kdenlive.

На диске во второй сессии были еще виндовые и маковские бинарники плееров и какой-то unknown файл метров на 97, видимо сжатая (зашифрованная?) копия низкого качества для лохов.

Я не занимаюсь такими вещами.

вот ты расскажи как будет не совпадать образ снятый с одного и того же диска в примерно одних и тех же условиях(условимся что царапин не появилось)? И как он будет не совпадать с другим новым диском? А главное как это повлияет на качество звука.

Удалось успешно поставить Whipper 0.5.1 в Ubuntu 16.04 i386 из этого PPA (нужные пакеты python-pycdio и whipper ставил в таком порядке через GDebi).
Пришлось перепаковать пакет whipper

mkdir tmp
dpkg-deb -R original.deb tmp
edit
chmod 775 -R tmp
dpkg-deb -b tmp fixed.deb

Depends: python:any (<< 2.8), python:any (>= 2.7.5-5~), cdparanoia, cdrdao, flac, libsndfile1,
python-cddb, python-gobject-2, python-musicbrainzngs, python-mutagen, python-pycdio, sox, swig,
gobject-introspection, python-gobject, python-setuptools, python-requests, libcdio-utils

Программа работает из командной строки и почти не имеет настроек. Сначала нужно произвести конфигурацию (проверка отключения кэша и оффсет привода):

whipper drive analyze
whipper offset find

whipper cd rip

Кстати, Rubyripper 0.6 падал из-за европейской кодировки freedb, говорят у Ruby вечно проблемы с кодировками. А падение Rubyripper 0.7 нагуглить не удалось, нет совпадений вообще.

Для этого надо использовать популярный Audio CD, который гарантированно есть в базе. Я использовал Smash!! - Freeway 2003

Один достаточно? EAC: There could be several pressings of a CD, so make sure that you get a match from at least two different CDs.

Без деревянных подставок за 300килорублей под sata кабель снимать рипы нещитово.

whipper offset find

Но зачем?

Прога рипает только потреково

Просто не нужно так делать.

Достаточно, это же только чтобы определить/подтвердить offset привода, который и так общедоступен. EAC'у нужно несколько дисков для AccurateRip, чтобы добавить в настройках неотключаемую галочку для успокоения пользователя «привод не совсем рухлядь и точные рипы делать способен». А если не способен, то совпадений по базе пользователь (другой риповалки, например, без этой проверки) просто никогда не дождется и не будет знать кто виноват.

## Хорошо тот коммент успел написать. У Йoты на пару часов интернет пропал по всей Сибири.

Это ты просто не сталкивался с артефактами от простых риповальщиков, а то бы по другому заговорил. Я слышал как они риповали тот кактусовый CD.

Но зачем?

Можешь сам добавить offset в конфиг.

Просто не нужно так делать

Я честно говоря не знаю можно ли делать образом. Если нельзя, попроси об этом разрабов.

Прога рипает только потреково
Просто не нужно так делать

Рип образом не поддерживается, чтобы не потакать пиратам, я так полагаю. Вы можете вставить свои 5 копеек.
А также Whipper не поддерживает теги из FreeDB, только из MusicBrainz (взято отсюда), а там далеко не всё есть.
Вот пример убогости базы MusicBrainz:
FreeDB
MusicBrainz
Так что EAC в Windows наше всё. Можно попробовать использовать в Wine (если не нададут по рукам, хотя работать должно норм, если доступ к raw устройству есть), но в Wine не работают плагины расширенных поставщиков.

Можешь сам добавить offset в конфиг

Нет, зачем тебе вообще оффсет?

Копируя образом весь диск, ты избегаешь ошибки позиционирования между треками. Т.е., все, на что влияет неправильно выставленный оффсет - это несколько семплов в начале и конце диска. Напомни, сколько там долей секунды длина семпла на audio cd? Ну вот. В итоге это ни на что не влияет. А уже после дампа образа режешь его на треки для удобного использования.

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

AccurateRip

Оказывается у него есть дальнейшее развитие. CUETools позволяет не только сообщить об ошибке, но и исправить небольшие ошибочные данные. Он доступен в виде плагина для EAC. Правда возможно это только для популярных дисков. Вообще там много всяких плагинов, в том числе платные (триальные) базы тегов. База freedb теперь требует .Net 2.0

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

рипает только потреково
появляются файлы cue

flac'и можно склеить shnjoin -o flac *.flac а cue получить через K3B (от Whipper'ского cue толку нет - он пофайловый). Геморно, но зато копия без ошибок. Не знаю только насколько корректной будет обработка пауз на бесшовых альбомах. Без CUETools базы можно обойтись и теги если что вбить вручную* (или утащить у K3B, а если копия побитово совпадет с рипом K3B, то можно оставить ее*). Главное, что есть проверка точности. Так что Whipper вполне юзабелен, для себя сгодится. Morituri можно даже не смотреть, он давно заброшен и поддерживает только AccurateRip v1, то есть бесполезен, но поставить можно. Если диска не будет в базе MusicBrainz, Morituri откажется копировать, пока его не зарегистрируешь.

* Команда запуска whipper cd rip --unknown

* В моем случае копия K3B была сдвинута по времени на величину offset привода (для 6 сэмплов это менее 1 мс), а в остальном волновая форма полностью идентична рипу Whipper (я проверил противофазным сравнением в Audacity с усилением разницы на 350 дБ). Кстати, Whipper жмет во FLAC с уровнем сжатия 5, это дефолтный уровень FLAC. В базе MusicBrainz использует только первое совпадение, а оно не всегда удачное.

UPD: На кактусовом CD Whipper конкретно призадумался и начал копировать один трек несколько раз подряд. K3B (в режиме паранойи 3, может это наоборот скоростной?) был гораздо быстрее. А EAC умеет перечитывать кусочками, а не файлами. После 5 попыток выдал ошибку
CRITICAL:whipper.command.cd:Giving up on track 1 after 5 times
track can't be ripped. Rip attempts number is equal to 'MAX_TRIES'

Rubyripper ничуть не хуже EAC

Увы, это не так, что бы ни думали разработчики. У меня есть CD, на котором один из треков неважно читается (заводской брак или DRM - не знаю). Так вот, Rubyripper его «успешно» снял. В его понимании, если снялось два раза одинаково, и при этом в промежутке прочитано много данных из других мест, то это правильно. По факту же, привод одинаково заменил нечитаемые семплы нулями. EAC же честно проверяет ошибки и отказывается выдавать рип.

А вы отправили баг-репорт разработчику?

Нет, не отправил, поскольку не считаю баг исправимым в RubyRipper. Если отправлять, то в cdparanoia.

Кстати cdparanoia устарела. Whipper в новых версиях использует cd-paranoia из проекта libcdio-paranoia (в репозиториях иногда называется libcdio-paranoia2 чтобы избежать путаницы и сам бинарный файл там может отсутствовать, по крайней мере в ubuntu/debian. Иногда под видом cdparanoia может быть новая cd-paranoia). Там вообще черт ногу сломит с этими пакетами. Внезапно, Whipper есть в официальных репозиториях Fedora.
А еще cdda2wav из проекта cdrtools продолжает традиции паранойи, но он есть официально по моему только в арче и вроде бы не поддерживает коррекцию offset.

cdparanoia > cd-paranoia (проект libcdio-paranoia)
cdparanoia > cdda2wav (проект cdrtools)

Rip Audio CDs - ArchWiki

А смысл в образе? Все равно в плеере по трекам будет разбито. Еще остались плееры, которые не умеют беспалевно переключаться с трека на трек?

Чуть ниже написал

Просто понятие gapless support довольно обширное:

1. При сжатии lossy кодеками (mp3, aac, vorbis) есть особенность сжатия, что кодеры добавляют в начало и конец немного тишины (задержка и паддинг, вроде как потому что, чтобы закодировать первый сэмпл им надо на что-то ориентироваться). И прописывают в метаданные для декодеров эту инфу: сколько они добавили. Умные плееры/декодеры это скомпенсируют и выдадут абсолютно точный поток по времени и содержимому. В lossless (flac, monkeys, wavpack) понятное дело такой проблемы нет. Однако, даже если декодер все корректно скомпенсировал, нужно чтобы...

2. Сам плеер мог переключать дорожки прозрачно. То есть, даже если ему скормить простые WAV'ы. Не всегда это возможно архитектурно. Если плеер (как SMPlayer) с каждым новым файлом инициализирует заново движок - щелчков при переключении не избежать.

Так что в плеере может быть реализован п.1, а п.2 не реализован или наоборот. А может быть реализованы оба. Проверить просто. Генерируете в Audacity стерео синусоиду 400 Гц, уровень 0.5, 10 секунд, экспортируете в wav. Потом wav сжимаете в mp3 с помощью консольного lame (он гарантированно корректно работает) и закидываете wav, flac и mp3 в ваш плеер. В Audacious, например, п.2 точно реализован.
А еще бывает альбом в mp3 изначально криво закодирован.

Для этого есть оффсет коррекция в риппере.

Правда из-за простого сигнала этот метод не позволит определить проглатывает ли плеер сэмплы, только появление щелчков и пауз. Если даже проглатывает, это не всегда заметно, только если на стыках большая разница амплитуд или если съедено много (больше ~20 мс). Для корректного сравнения нужно записать все, что воспроизводит плеер (лучше с другого компа) и сравнить звуковую волну с оригиналом в аудиоредакторе. Не синус, а обычную музыку.

Audacious 3.6.2 (Ubuntu 16.04) некорректно обрабатывает паддинги mp3. Это значит, что при переходах между mp3>mp3 или mp3>flac может быть щелчок. mp3 delay в начале обрабатывается нормально, если он вообще есть. Конечно, заметно это будет только на альбомах, где нет пауз между треками (Live's, концерты в mp3).

шел 21 век, а линуксовые плееры так и не научились в gapless playback...

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

mp3 160kbit jointstereo, записанный с линейного входа alc655 это лучше, что придумало человечество, а сторонники точного копирования cd должны страдать.

mp3 160kbit

Отстой какой. Opus 64 kbps порвет его как тузик грелку. Даже FDK/QAAC 128 kbps получше будут. А вообще-то порог прозрачности современных кодеров ~200 kbps.

сторонники точного копирования cd должны страдать

А мазохисты - сторонники ошибок не должны, они уже страдают.

Ну на ЛОРе и контингент уровня яплакал. На торовских сайтах и то интеллигентнее.

А я пользуюсь WavPack

поскольку не считаю баг исправимым в RubyRipper

Возможно проблема в этом диске. Например, EAC не может copy selected tracks index-based в этом диске. С другими дисками нет такой проблемы. А этот — особенность.

У меня таких проблем не было. Если будут какие-то сбои рип просто не пройдет онлайн проверку, в этом вся фича.

Кстати, отправлять результаты в базу доверяют только пользователям EAC (раз в месяц) и dBpoweramp (AR их разработка, EAC только лицензирует). Так что эти пользователи нужны.

отправлять результаты в базу доверяют только пользователям EAC

Ну, ССЗБ, что я могу сказать. А я себе сдампил диски имеющимися в Linux инструментами.

Хакеры воспользуются открытым кодом и изгадят базу левыми данными.

Хотел написать скрипт, сверяющий рипы Whipper и K3B, чтобы можно было выбрать какой оставить. У K3B преимущество в том, что он лучше ищет теги. Жалко, что я не программист, поэтому жуткое быдлокодие задумано. Разобрался таки как вырезать 6 сэмплов тишины из одного файла в начале и приклеить столько же другому файлу в конец. Если бы еще кто подсказал, как в скрипте найти flac файлы из двух неизвестных подпапок, это бы сократило ручной труд.

как в скрипте найти flac файлы из двух неизвестных подпапок

Задача не ясна

Ну смотри, прога рипает. Создает папку (album, soundtrack, unknown, может еще как-то зависит от диска), а в ней еще папку «название альбома». А мне бы сделать cd первая_папка/название_альбома или cp /root_folder/первая_папка/название_альбома/*.flac /root_folder/*.flac