Я коллекционирую музыку: покупаю компакт-диски, оцифровываю их программой Exact Audio Copy, сканирую обложки и вкладыши. Иногда это непросто, если CD издан ограниченным тиражом за рубежом 10 лет назад. Сложнее всего, если на компакте производственный дефект — и некоторые треки не читаются.

Альбом аранжировок для фортепиано ????? от Altneuland вышел в 2005 году. Я нашёл его спустя три года (вероятно, на YouTube), скачал лучшую копию — и внёс диск в список будущих покупок. Последние достижения в технологиях международной почты позволили в прошлом году купить бэушный диск. К сожалению, ни один из моих CD-приводов не смог прочитать трек № 3. Такое часто бывает при покупке старых дисков, особенно когда они прошли через центр международной доставки USPS. Я отложил его и начал искать другой экземпляр, который нашёл в прошлом месяце. Он прибыл в пятницу — и я сразу же попытался его рипнуть. Но с толкнулся с точно такой же ошибкой. Похоже, тут дело не в износе или повреждении — вероятно, диск вышел дефективным прямо с завода.

ДОПОЛНЕНИЕ: После проведённого расследования я больше не считаю, что это заводской дефект. Когда я записываю начало или конец сбойной дорожки на пустой CD-R и копирую его, то риппер выдаёт ту же ошибку! Попробуйте сами с файлом minimal.flac.

Осталось два варианта: или попытаться когда-нибудь найти другую копию, которая будет успешно копироваться (маловероятно), или каким-то образом восстановить исходные звуковые данные c повреждённых дисков. Вы уже знаете, какой вариант я выбрал.

Как работает риппер



EAC не смог прочитать трек № 3 с диска [?????]

CD хранят цифровые данные, но между дисками, лазерами и оптическими диодами вполне аналоговый интерфейс. Ошибки чтения возникают по разным причинам: грязный носитель, царапины на защитном слое поликарбоната, вибрации самого привода. Примитивные коды коррекции ошибок в стандарте CDDA помогают минимизировать звуковые искажения на редко используемых дисках, но не способны полностью восстановить битовый поток на CD с большим количеством ошибок. Современные рипперы решают проблему с помощью двух важных методов обнаружения ошибок: избыточного чтения и AccurateRip.

На странице EAC: Extraction Technology описано, как EAC производит избыточное чтение:

В безопасном режиме программа считывает каждый сектор минимум дважды [...] Если возникает ошибка (чтения или синхронизации), то программа продолжает считывать этот сектор до тех пор, пока 8 из 16 попыток не окажутся идентичными. Такая процедура проводится максимум один, три или пять раз (в соответствии с выбранным качеством восстановления ошибок). Так что в самом худшем случае плохие сектора считываются 82 раза!

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

Эта статья о том, что делать, если оба метода не могут помочь. EAC не даёт результат, если каждое чтение возвращает разные данные, а в базе AccurateRip только одна запись о редком диске [1].

«Я миновал десять тысяч проходов, десять тысяч проходов, чтобы увидеть вас»



Оптические приводы Asus, LG, Lite-On, Pioneer и неизвестного OEM

Если CD не копируется, то логично использовать другой привод. Иногда конкретная модель более снисходительно относится к спецификациям CDDA или там лучшая прошивка для исправления ошибок, или что-то ещё. На форуме DBpoweramp есть рейтинг точности приводов CD/DVD, чтобы выбрать наиболее подходящий привод для рипа.

В субботу утром я купил пять новых CD-приводов разных производителей [2], попробовал их все — и нашёл тот, который смог держать синхронизацию на битом треке. К сожалению, подтверждение рипа не удалось получить — между всеми рипами выходило около 20 000 отличающихся байт.

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

«Количество переходит в качество»


Я начал с многократного копирования диска на одном из приводов, записи всех значений для каждого байта и объявления ошибки «исправимой», если более половины рипов выдаёт определённое байтовое значение для данной позиции. Начало было хорошим: количество неисправимых ошибок уменьшилось почти с ~6900 байт при N=4 до ~5000 байт при N=10. Выгода от каждого дополнительного рипа снижалась с течением времени, пока примерно на N=80 число неисправимых ошибок не стабилизировалось на уровне ~3700. Я прекратил рипы при N=100.


Исправленные и неисправимые ошибки на количество rip

Затем я попытался 100 раз скопировать диск на втором приводе и использовать две карты коррекции, чтобы «заполнить» неисправимые позиции ошибок с первого привода. Но не получилось: на каждом приводе оказались тысячи исправлений, которые не соответствовали исправлениям на другом! Оказывается, нельзя устранить шум, совместив его с другим, но связанным источником шума.


То же самое, но для двух дисков с перекрёстной проверкой исправлений

Кустарное творчество




На сайте EAC есть ещё один хороший ресурс: тест качества DAE, который определяет качество прошивки привода по уровню исправляемых ошибок. Это более низкоуровневая обработка ошибок, когда привод исправляет ошибки чтения, а не просто сообщает о них. Загвоздка в том, что «безопасный режим» EAC доступен только при отключении этого встроенного кода коррекции ошибок, предполагая его неправильную работу.

Я подготовил тест путём прожига файла .wav на CD-R, выделив точный сектор на поверхности данных и осторожно закрасив его чёрным маркером. Вот это — гарантированные неустранимые ошибки по детерминированному шаблоне.

Я протестировал всех приводы и получил два интересных результата:



Привод Lite-On я прежде использовал, чтобы обойти ошибки синхронизации. Он с удовольствием прожевал волшебный маркер, но его сильно смутили прямые линии на поверхности данных. Вы можете видеть, как вместо трёх раздельных пиков справа один гигантский сбойный блоб.

Errors total Num : 206645159
Errors (Loudness) Num : 965075 - Avg : -21.7 dB(A) - Max : -5.5 dB(A)
Error Muting Num : 154153 - Avg : 99.1 Samples - Max : 3584 Samples
Skips Num : 103 - Avg : 417.3 Samples - Max : 2939 Samples

Total Test Result : 45.3 points (of 100.0 maximum)




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

Errors total Num : 2331952
Errors (Loudness) Num : 147286 - Avg : -77.2 dB(A) - Max : -13.2 dB(A)
Error Muting Num : 8468 - Avg : 1.5 Samples - Max : 273 Samples
Skips Num : 50 - Avg : 6.5 Samples - Max : 30 Samples

Total Test Result : 62.7 points (of 100.0 maximum)


«С определённого момента числа имеют значение»


Как использовать прошивку Pioneer с хорошим исправлением ошибок, если «безопасный режим» EAC игнорирует её? Очень просто: переключите EAC в «пакетный режим» (burst mode) и записывайте на диск поток битов в том виде, в каком их сообщает прошивка. Как потом превратить эту кучу непроверенных файлов .wav в файл хорошего качества, как в «безопасном режиме»? Да тем же инструментом анализа ошибок, который мы использовали в рипах с Lite-On!

После нескольких настроек конфигурации EAC и через сто рипов мы получаем такую красивую диаграмму.


Исправленные и неисправимые ошибки на количество рипов (Pioneer)

Что можно отметить:

  • Неисправимые битовые ошибки быстро стремятся к нулю, но никогда его не достигают.
  • Огромный скачок исправленных ошибок в 53?54 рипах.
  • Количество ошибок до и после этого большого скачка практически не изменяется, что указывает на области стабильности в скопированных данных.

0xA595BC09


Используя почти идеальную коррекцию ошибок от Pioneer, я сгенерировал файл «лучшее предположение» и начал сравнивать его с рипами Pioneer. Как и ожидалось, обнаружилось несколько некачественных участков, которые я исправил, сделав ещё 10 рипов:

$ for RIP_ID in $(seq -w 1 100); do echo -n "rip$RIP_ID: "; cmp -l analysis-out.wav rips-cd1-pioneer/rip${RIP_ID}/*.wav | wc -l ; done | sort -rgk2 | head -n 10
rip054: 2865
rip099: 974
rip007: 533
rip037: 452
rip042: 438
rip035: 404
rip006: 392
rip059: 381
rip043: 327
rip014: 323


Я также нашёл что-то действительно интересное: несколько рипов выдавали абсолютно одинаковый контент! Помните, ведь это как раз критерий успеха в «безопасном режиме» EAC. Команда shncat -q -e | rhash --print="%C" используется для вычисления контрольной суммы CRC32 необработанных аудиоданных: именно её применяет EAC.

$ for wav in rips-cd1-pioneer/*/*.wav; do shncat "$wav" -q -e | rhash --printf="%C $wav\n" - ; done | sort -k1
[...]
9DD05FFF rips-cd1-pioneer/rip059/rip.wav
9F8D1B53 rips-cd1-pioneer/rip072/rip.wav
A2EA0283 rips-cd1-pioneer/rip082/rip.wav
A595BC09 rips-cd1-pioneer/rip021/rip.wav
A595BC09 rips-cd1-pioneer/rip022/rip.wav
A595BC09 rips-cd1-pioneer/rip023/rip.wav
A595BC09 rips-cd1-pioneer/rip024/rip.wav
A595BC09 rips-cd1-pioneer/rip025/rip.wav
A595BC09 rips-cd1-pioneer/rip026/rip.wav
A595BC09 rips-cd1-pioneer/rip027/rip.wav
A595BC09 rips-cd1-pioneer/rip028/rip.wav
A595BC09 rips-cd1-pioneer/rip030/rip.wav
A595BC09 rips-cd1-pioneer/rip031/rip.wav
A595BC09 rips-cd1-pioneer/rip040/rip.wav
A595BC09 rips-cd1-pioneer/rip055/rip.wav
A595BC09 rips-cd1-pioneer/rip058/rip.wav
AA3B5929 rips-cd1-pioneer/rip043/rip.wav
ABAAE784 rips-cd1-pioneer/rip033/rip.wav
[...]


Тем временем повторные рипы некачественных участков позволили завершить анализ с нулём неисправимых ошибок. И когда я проверил этот файл, там был точно такой же аудиоконтент, как и в «обычном» рипе! Этого достаточно, чтобы объявить победу.

Я на 99% уверен, что успешно скопировал этот проблемный компакт-диск, а 0xA595BC09 является правильной CRC-суммой для трека № 3.

Приложение A: compare.rs


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

extern crate memmap;

use std::cmp;
use std::collections::HashMap;
use std::env;
use std::fs;
use std::sync;
use std::sync::mpsc;
use std::thread;

use memmap::Mmap;

const CHUNK_SIZE: usize = 1 << 20;

fn suspect_positions(
    mmaps: &HashMap<String, Mmap>,
    start_idx: usize,
    end_idx: usize,
) -> Vec<usize> {
    let mut positions = Vec::new();
    for ii in start_idx..end_idx {
        let mut first = true;
        let mut byte: u8 = 0;
        for (_file_name, file_content) in mmaps {
            if first {
                byte = file_content[ii];
                first = false;
            }
            else if byte != file_content[ii] {
                positions.push(ii);
                break;
            }
        }
    }
    positions
}

fn main() {
    let mut args: Vec<String> = env::args().collect();
    args.remove(0);
    let mut first = true;
    let mut size: usize = 0;

    let mut files: Vec<fs::File> = Vec::new();
    let mut mmaps: HashMap<String, Mmap> = HashMap::new();
    for filename in args {
        let mut file = fs::File::open(&filename).unwrap();
        files.push(file);
        let mmap = unsafe { Mmap::map(files.last().unwrap()).unwrap() };
        if first {
            first = false;
            size = mmap.len();
        } else {
            assert!(size == mmap.len());
        }
        mmaps.insert(filename, mmap);
    }

    let (suspects_tx, suspects_rx) = mpsc::channel();

    let mut start_idx = 0;
    let mmaps_ref = sync::Arc::new(mmaps);
    loop {
        let t_start_idx = start_idx;
        let t_end_idx = cmp::min(start_idx + CHUNK_SIZE, size);
        if start_idx == t_end_idx {
            break;
        }

        let mmaps_ref = mmaps_ref.clone();
            let suspects_tx = suspects_tx.clone();
            thread::spawn(move || {
                let suspects = suspect_positions(mmaps_ref.as_ref(), t_start_idx, t_end_idx);
                suspects_tx.send(suspects).unwrap();
            });
        start_idx = t_end_idx;
    }
    drop(suspects_tx);

    let mut suspects: Vec<usize> = Vec::with_capacity(size);
    for mut suspects_chunk in suspects_rx {
        suspects.append(&mut suspects_chunk);
    }
    suspects.sort();

    println!("{{\"files\": [");
        let mut first_file = true;
        for (file_name, file_content) in mmaps_ref.iter() {
            let file_comma = if first_file { "" } else { "," };
            first_file = false;
            println!("{}{{\"name\": \"{}\", \"suspect_bytes\": [", file_comma, file_name);
            for (ii, position) in suspects.iter().enumerate() {
                let comma = if ii == suspects.len() - 1 { "" } else { "," };
                println!("[{}, {}]{}", position, file_content[*position], comma);
            }
            println!("]}}");
        }
    println!("]}}");
}

1. В этой единственной записи AccurateRip к моему диску совпадают CRC для всех треков, кроме трека № 3: там указана сумма 0x84B9DD1A, а у меня 0xA595BC09. Подозреваю, что тот риппер не понял, что у него плохой диск. [вернуться]

2. Очевидный вопрос при покупке CD- или DVD-привода в 2018 году: «Блин, а где ж их купить?». И мне нужен был не один, а несколько от разных брендов. Я знаю только один магазин поблизости, у которых в наличии есть DVD-приводы 5,25". Только один магазин достаточно большой, чтобы не пожалеть место на полках на такие приводы, и достаточно странный, чтобы они не казались там неуместными. Конечно, я говорю о Frys Electronics. [вернуться]

Комментарии (74)


  1. rSedoy
    02.08.2018 12:47
    +1

    сразу в голове всплыла ассоциация — Teac


    1. paranoya_prod
      02.08.2018 12:58
      +1

      Или Plextor.
      В своё время, Н-дцать лет назад, перебирались не только производители, но и модели, даже был один старенький и медленный именно CD-привод, для проблематичных дисков.


      1. Caelwyn
        02.08.2018 13:08
        +2

        Teac CD-520?


        1. paranoya_prod
          02.08.2018 14:35

          Не помню. Данные об этом стёрлись из памяти. :)


          1. Caelwyn
            02.08.2018 15:32
            +1

            У меня тоже, но не совсем, всё таки CD-540.

            image


            1. Javian
              02.08.2018 15:46

              off К cлову фото не показывает насколько у него длинный корпус


              1. stychos
                02.08.2018 22:31
                +1

                Я из такого делал «CD-плеер» в коробке из-под обуви с АТ-шным блоком питания (который тумблером включается-выключается).


                1. Smayliks
                  05.08.2018 13:30

                  Сидюк без кнопки плей? Надо было лучше искать, с пеем были ;-)


                  1. stychos
                    05.08.2018 14:53

                    В то время это было чертовски дорого, так что радовались тому, что было )


              1. Chatter_A
                03.08.2018 00:46

                И вес )
                Проверил — работает, чертяка!
                image


    1. lubezniy
      03.08.2018 23:37

      Угу… из всех пятидюймовых флоппи-дисководов для ZX Spectrum в России были лучшими.


  1. TheSskain
    02.08.2018 12:48
    +1

    Многократно сталкивался с аналогичными траблами при риповании.
    В 99.9% случаев это легко вылечивалось переходом, на том же приводе даже, с модели tracks+.cue на image+.cue. Моментально получались правильные рипы, без сбоев.
    В чём секрет этой магии — так за много лет и не понял.


    1. DASpit
      02.08.2018 22:26

      Раньше добавление "битых" треков в оригинальный образ CD было одним из способов защиты диска от копирования.


      Не имеет смысла править аудио CD рип, поскольку такие ошибки на слух не различимы.


      1. TheSskain
        02.08.2018 22:56

        Битый — это нечитаемый?
        Тогда на слух разницы не будет — трек просто невозможно будет воспроизвести никаким способом, ни ЕАСом рипнуть, ни бытовым плеером прокатать.


        Если же битые вейвформы, ака глитчи etc — то они, при рипе, ничем не отличаются от обычного звука и проблем с рипами не создают никогда.


        Ломали ещё TOC, для защиты, но это прекрасно обходится EAC 0.95b3


        1. khim
          03.08.2018 01:13

          Битый — это нечитаемый?
          Угу. «Бытовой» поигрватель их проскакивал и интерполировал, скажем, тишину. А при попытке сделать рип — программа в этом месте «залипала»…


          1. TheSskain
            03.08.2018 02:41

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


            1. khim
              03.08.2018 04:25

              «Бытовая балалайка» заточена под работу на скорости 1x. Если она не может считать что-то с диска — «додумывает». Как может.

              А компьютерные приводы останавливаются и начинают пытаться считать сектор повторно.


              1. TheSskain
                03.08.2018 05:20

                Так комповые приводы могут работать и на меньших, нежели х1.
                Не в скорости дело.


                И в "додумывании" балалайки зело ограничены — нет у них ни мозгов, ни ресурсов, для этого дела.


                1. Stanislavvv
                  03.08.2018 09:32

                  Вот поэтому и не было проблем при прослушивании — тупо проигрывали тишину в битых местах. А с рипом — таки проблемы…


                  1. TheSskain
                    03.08.2018 14:36

                    Так воспроизведение "внезапной" тишины — это глитч. Слышимый и осязаемый.


                    1. Stanislavvv
                      03.08.2018 16:57

                      Заранее битые сектора были как раз там, где должна быть тишина :-)


                      1. TheSskain
                        03.08.2018 18:29
                        +1

                        Абракадабра кракозябровая?
                        Это идёт поперёк Red_Book и идинаково не переваривается балалайками и приводами ибо нестандарт и сценарии обработки отсутствуют.


                        1. khim
                          03.08.2018 21:14

                          Балалайки это как раз переваривают. А что это нарушение какой-то там странной книги — кого это волнует, если продажи растут?

                          Если хочется уж совсем большой совместимости — ну добавьте туда дорожек с данными.

                          «Балалайка» их пропустит, так они её не интересуют. А компьютерный привод на них зависнет, если туда что-нибудь полезное с точки зрения PC положить (ну там корень файловой системы, к примеру).


                          1. TheSskain
                            03.08.2018 21:48
                            -3

                            Это не странная книга, а стандарт CDDA.
                            Продажи не могут расти ибо компакт-диск (cdda) — де факто умерший формат, вместе с dvd etc


                            Приводу нет смысла зависать, ибо он лишь считывает питы, равно как и балалайка. Интерпретация считанных питов — вне компетенции читалки.


  1. stalinets
    02.08.2018 12:54
    +1

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

    Вот куда сложнее найти, скажем, привод, поддерживающий LightScribe.


    1. ipswitch
      02.08.2018 13:20

      … или что-то редкое, типа Yamaha CRW-F1 с технологией DiscT@too, предшественником LabelFlash.
      Мне вот ещё рабочий PD-ROM привод нужен на SCSI. И крайне желательно не за 200$ с eBay…


      1. Zettabyte
        03.08.2018 08:53

        что-то редкое, типа Yamaha CRW-F1 с технологией DiscT@too
        У меня есть, всего несколько дисков на нём записал в итоге. /не знаю какой смайлик здесь поставить — весёлый или грустный/

        Даже retail-коробка и всё из неё в наличии. Плюс банка «красивых» тёмно-синих CD-R Verbatim, которые идеально подходят для DiscT@too.


  1. zuborg
    02.08.2018 13:47

    Что-то я не совсем понял, почему при сотне рипов просто не посчитать для проблемных бит сколько раз какое значение встретится?
    Если на 95 нулей 5 раз всплыла единица (при отключенной коррекции, разумеется), то результат очевиден. Ладно там на 60 нулей было 40 единиц, ещё можно посомневаться, но я не думаю, что такие случаи вообще были.


    1. VBKesha
      02.08.2018 14:10

      90% что не всё так просто. На диске данные хранятся не совсем как 1 или 0. Там идет последовательность из 14 бит которые потом по таблице приводится к 8 битам. Поэтому искажения одного бита при чтении будет приводить к совсем другому байту. А там ещё есть соединяющие биты которые скорей всего и были криво рассчитаны для этого диска(или намеренно искажены).


      1. zuborg
        02.08.2018 14:13

        Алгоритм приведения известен? Эти 14 бит прочитать сто раз можно? Тогда можно восстановить корректные 14 сырых бит и из них получить корректные 8 бит данных.


        1. VBKesha
          02.08.2018 14:23

          Ты можешь прочитать только сектор. Который уже прошёл обработку из 3 стадий. И как раз после эти 3 стадий ты знаешь что сектор(на компакте он 2352) прочитан, и что прочитан с ошибкой. Причём ошибка может быть в данных а может быть в кодах коррекции. И ты можешь хоть 1000 раз прочитать сектор но ты каждый раз имеешь статус ошибка чтения, даже если данные каждый раз совпадали это не значит что они прочитаны верно это значит что ошибка чтения стабильно повторяется. Там заморочек хватает, бывали даже образы компактов, которые после записи на болванку не читались 90% приводов из за хитрой последовательности байт.


          1. zuborg
            02.08.2018 15:31

            Почитал спеки на формат CD — проблема в том, что данные на поверхности не представлены непосредственно битами — они представлены питами (выжженые лазером участки) и промежутками между ними (лендами), причем и питы и ленды кодируют последовательности нулей, а вот переходы между ними (с пита на ленд и наоборот) — одну единичку. Кодирование 8 <-> 14 нужно, чтобы между каждой единичкой было от 2 до 10 нулей. И вот тут да, возникают проблемы синхронизации — длина пита или ленда может считываться по разному и это будет влиять на декодирование последующих бит, пока не встретится синхронизирующая последовательность… Технически, можно было бы построить модель и восстанавливать структуру питов и лендов на поверности и находить проблемные участки, но это не так просто, как посчитать кол-во нулей и единичек, да.


            1. walti
              02.08.2018 18:03

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


          1. bzq
            03.08.2018 09:30
            +2

            И это только проблема так называемого jitter-а, то есть неустойчивого чтения сигнала. А есть ещё и так называемая проблема синхронизации. В стандарте CD-DA отсутствует информация о начале трека и номер этого трека в самом читаемом блоке. В цифровых CD в 2352 байт на данные остаётся 2048, остальное занято структурами, позволяющими понять, что это и правильно ли прочиталось. А в аудио-CD (которые CD-DA) идёт просто поток байтов в одну дорожку. Как на виниле. Никаких отметок, что у нас начался однатысячакакойтотам сектор нет и в помине. Поэтому драйв, когда его просят прочесть однатысячакакойтотам сектор, тщательно прицеливается и что-то читает. Иногда не одно и то же, если промахивается на несколько байт или несколько десятков-сотен байт…

            Развлекался я таким под OS/2 двадцать лет назад. Уже перезабыл почти всё. Но даже на фоне моих давно забытых знаний статья автора (переводчик, надеюсь, не виноват) выглядит забористым бредом. Это уже однако тенденция, когда народ по какой-то левой документации (в данном случае к EAC) пытается понять находядщиеся в свободном доступе стандарты (в данном случае Red Book, в которой описан стандарт cd-da). Софтина конечно была знатная, но кто мешал автору почитать стандарты и не городить кучу необоснованных выводов о том, что прочиталось с диска? Не в первый раз уже встречаю, что народ вместо изучения имеющейся доступной информации начинает гадать на кофейной гуще. Неонеандертальцы какие-то.


  1. Pentoxide
    02.08.2018 15:38

    Сам пользовался Exact Audio Copy, и один раз попался диск который вообще практически не читался без ошибок, но когда прослушал получившийся wav — понял что на слух всё чисто и забил.
    Объясните мне пожалуйста вот это копирование без ошибок из статьи это что-то типа вещи в себе или это реально как-то заметно было при прослушивании?


    1. vlad_bo
      02.08.2018 17:10

      Вот действительно! Парень, настолько заморочился высокой верностью считывания, что непонятно, были ли слышны хоть какие-то артефакты на слух?
      А если были, не проще ли исправить их в аудиоредакторе, тем более что их там не только слышно, но и видно?

      Как-то так:
      image image

      Правда, тогда статья была бы совершенно о другом…


  1. Daddy_Cool
    02.08.2018 16:13

    Вау! Я впечатлен!
    Вот это особенно: "я купил пять новых CD-приводов"
    Можем ли мы теперь насладиться эпичным треком №3?


    1. Ryav
      02.08.2018 18:24

      А я вообще не увидел 3 трека в треклисте по ссылке.


      1. Murimonai
        02.08.2018 21:17

        Там сноска, где говорится, что трек номер три — Пронтера из Рагнарок Онлайн, причем оригинальный образ.
        1 ????3??????????????????????????????
        Так что подозреваю, он там есть, но не указан по тематическим соображениям или чего-то такого.


      1. TaskForce141
        03.08.2018 00:46

        The End of Theocratic Era.opus
        Посчастливилось найти при помощи поисковика. Активных торрентов с раздачей TLMC, к сожалению, не нашел. Вот ссылка на данный конкретный трек (№3) на стороннем ресурсе:
        тык


        1. n0isy
          03.08.2018 14:06

          Пришлите пожалуйста mp3 120 kbps, я дальше не различаю разницу… ))


          1. TaskForce141
            03.08.2018 21:52
            +1

            Посыпаю голову пеплом — предыдущий комментатор, судя по всему, прав. Я же просто счел треком №3 то, что привычно мне самому.
            В любом случае, вот mp3 (128kbps) того трека, который ошибочно указал я: <тык>



  1. Chosen_One
    02.08.2018 16:40
    +4

    Вспоминается бородатая история www.ixbt.com/optical/magia-chisel.shtml (Опубликовано — 24 декабря 2003)


    1. khim
      02.08.2018 16:49
      +1

      Меня удивлят, что на эту «магию чисел» автор не сослался.

      Кстати фраза «после проведённого расследования я больше не считаю, что это заводской дефект» и верна и неверна одновременно: да, это не проблема завода, это проблема образа!

      Как-то в процессе подготовки образа диска вместо нормальных звуков туда попали вот эти самые «магические» числа (случайно этого произойти не может, наша вселенная слишком молода для этого). Соответсвенно прочитать это обратно — невозможно… да и не нужно: в этом месте оригинального звука, так или иначе, нету. Он был потерян ещё в студии…


      1. ValdikSS
        02.08.2018 17:17

        Автор не говорит по-русски.



  1. achekalin
    02.08.2018 16:57
    -1

    Ответа на вопрос «зачем» так и не приведено. Если цель только в том, чтобы именно этот трек именно с этого издания дисков прочесть — то, наверное, автор прав, но если проснушать трек, то, кажется, есть много обходных способов заполучить трек в виде файла и услышать искомое.
    Более того, автор, как пишет, треки-то скачал, так что…


    1. xcore78
      03.08.2018 00:36

      Автор скачал lossy, а получить хотел lossless со своего легального носителя. Это спорт/хобби, здесь не ставится вопрос «зачем», только «как».


  1. ivlis
    02.08.2018 17:10

    На слух есть какая-то разница между стабильным рипом и нестабильным?


  1. Naves
    02.08.2018 18:04

    Я читаю комментарии перед отправкой

  1. BigD
    02.08.2018 18:34

    У меня есть старые CD-R и DVD-R самописные с домашним видео (приличным абсолютно). Подскажите, как восстановить файлы, которые не считываются?


    1. LanMaster
      02.08.2018 20:50

      Часто может помочь IsoBuster


    1. VBKesha
      03.08.2018 10:02

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


    1. Osnovjansky
      04.08.2018 23:18

      Для некоторых CD помогало чтение не на DVD-RW приводе, а на старом CD-RW


  1. LanMaster
    02.08.2018 20:49

    До сих пор валяется хвалёный Teac CD-540E, который не справился с наглухо убитым аудио CD Arabesque, поцарапанным путём пинания по асфальту до невменяемого состояния. Воспроизведение просто останавливается посреди песни через каждые пару секунд. И есть второй, Sony CRX210E1, который этот диск правильно воспроизводит без остановки, треки целиком. C ощутимым кваканьем-шелестом, искажениями от ретуширования (маскировки) невосстановимых ошибок, но — без остановок.


    1. khim
      02.08.2018 22:48
      +3

      Вот это комментарий — с плюсиком… прямо в рамочку и на стену…

      Ибо он олицитворяет смерть Хабра, в некотором смысле.

      Читаем:

      До сих пор валяется хвалёный Teac CD-540E, который не справился с наглухо убитым аудио CD Arabesque, поцарапанным путём пинания по асфальту до невменяемого состояния.
      Ох ты ж, блин… А что значит «не справился», интересно?

      Воспроизведение просто останавливается посреди песни через каждые пару секунд.
      Ну то есть когда на скорости 1x считать не получается, то привод снижает скорость до 0.5x, до 0.1x и так далее — пока не прочитается… Чем, собственно, он и славится…

      И есть второй, Sony CRX210E1, который этот диск правильно воспроизводит без остановки, треки целиком.
      Вау! Круто-то как! Порченный диск, а всё читается быстро и правильно. Хачю, хачю, хачю…

      C ощутимым кваканьем-шелестом, искажениями от ретуширования (маскировки) невосстановимых ошибок
      Ох ты ж… ну то есть как и всегда для приводов SONY — достаточно диску оказаться чуть-чуть неидеальным и всё, оригинального звука — нет как нет? Это называется «правильно воспроизводит»?

      но — без остановок
      Вам не кажется, что в контексте создания статьи об «идеальных рипах» это — как раз дело десятое?

      Да, представьте себе, если пытаться отвёрткой закрутить шуруп — будет проблемы… а молотком его можно-таки быстро забить… если вас не интересует результат. Если же результат таки интересен, то лучше использовать молоток для забивки гвоздей, а шурупы заворачивать отвёрткой…


      1. LanMaster
        03.08.2018 08:23

        достаточно диску оказаться чуть-чуть неидеальным
        — жаль, что потерял его где-то и не могу показать вам его «чуть-чуть неидеальность». С точки зрения конечного пользователя (а не техноманьяка, как автор статьи) Sony действительно в данном случае использования более привлекателен. А серьёзные царапины и дефекты на дисках — скорее, правило, а не исключение.


        1. mayorovp
          03.08.2018 09:36

          Да даже с точки зрения конечного пользователя, прослушивание музыки с диска и изготовление его цифровой копии (рип) — совершенно разные задачи с разными критериями качества! А вы даже не заметили как подменили одну из них другой.


          1. LanMaster
            03.08.2018 10:09
            -1

            прослушивание музыки с диска и изготовление его цифровой копии (рип) — совершенно разные задачи

            Само собой, ведь рип же не для прослушивания делают. [/sarcasm]
            Понимаю, что есть товарищи, которые ради «точности аудиоданных» способны покупать «аудиокабели из бескислородного золота». Но спорить о целесообразности таких мер не хочу.


            1. mayorovp
              03.08.2018 10:16

              рип делают чтобы прослушать позже. Эта задача отличается от прослушивания прямо сейчас.


        1. khim
          03.08.2018 21:24
          +1

          — жаль, что потерял его где-то и не могу показать вам его «чуть-чуть неидеальность».
          В данном случае вопрос не в том, как привод воспроизводит ваш «убитый» диск, а в том, как он снимает данные с дисков в чуть лучшем состоянии.

          Это разные задачи — и вот тут даже объясняется почему в этом процессе разные приводы «неодинаково полезны».

          Впрочем вам про это уже говорили, что на пользу явно не пошло.


          1. LanMaster
            04.08.2018 07:29

            вопрос не в том… а в том
            О чём «в данном случае вопрос», я прекрасно вижу и без ваших подсказок. Похоже, это вовсе не я здесь потерялся в темах обсуждения и капитанствую о неодинаковой полезности разных приводов для точного до бита снятия данных с аудиодиска, где эти биты отсутствуют.


      1. LanMaster
        03.08.2018 10:32

        Слова «правильно воспроизводит», к которым Вы прицепились, относились к непрерывности трека при воспроизведении, а не к безошибочности данных, читаемых с напрочь убитого диска, на котором нужная информация отсутствовала физически. Простите, что выразившись несколько туманно, я нечаянно наступил на вашу мозоль профессионализма и педантичности. Только педантичные профессионалы спасут Хабр!


  1. greabock
    02.08.2018 22:34
    +1

    Ну а послушать-то этот злосчастный трек можно? )


  1. Sabubu
    02.08.2018 23:15

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


  1. amarao
    03.08.2018 00:48

    Увидел код. Не поверил. Перечитал имя файла. Rust? Внезапно.


  1. JerleShannara
    03.08.2018 04:36

    Я дурные диски рипаю на старом сказёвом pinnacle micro, который более 2x вообще не умеет.


  1. Spaceoddity
    03.08.2018 08:49

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


    1. khim
      03.08.2018 21:25

      Всё возможно. Вопрос в цене.


  1. Fil-Cot
    03.08.2018 14:04

    С опозданием, но всё же напишу -вам следовало не пять драйвов покупать, а один, но середины 90-х, желательно scsi и низкоскоростной до 8x. В то время, такие компании как Apple, MATSUSHITA, IBM, Plextor выпускали cd-drive ещё не на шаговых, а аналоговых двигателях. И в этом была вся прелесть, минимум электроники позволял считать все треки в память и только оттуда уже программно обработать полученное, что для вас и требовалось. Потери были бы минимальны.


    1. VJean
      03.08.2018 15:53

      Вообще-то это перевод


    1. TheSskain
      03.08.2018 17:04

      Кстати — да.
      Или, хотя бы, использовать приводы не умеющие писать.
      Этот совет я получил в античные времена от аксакалов — и метод работает. Проверено на сотнях рипов.
      Причины сего волшебства мне неведомы..


  1. a_boy
    03.08.2018 21:53

    было дело не читался/не копировался файл на cd или dvd, взял пасту ГОИ нанес на ватку или войлок, потер, сама поверхность стала мутной, но прочиталось без проблем.