Saya mengumpulkan musik: Saya membeli CD, mendigitalkannya dengan Salinan Audio yang Tepat , dan memindai sampul dan sisipan. Terkadang tidak mudah jika CD dirilis dalam edisi terbatas di luar negeri 10 tahun yang lalu. Hal yang paling sulit adalah jika CD memiliki cacat produksi - dan beberapa trek tidak dapat dibaca.

Album aransemen Altneuland 帰 る べ き 城 dirilis pada tahun 2005. Saya menemukannya tiga tahun kemudian (mungkin di YouTube), mengunduh salinan terbaik - dan memasukkannya ke dalam daftar pembelian di masa mendatang. Kemajuan terbaru dalam teknologi email internasional telah memungkinkan untuk membeli disk yang digunakan tahun lalu. Sayangnya, tidak ada drive CD saya yang bisa membaca trek nomor 3. Ini sering terjadi ketika membeli disk lama, terutama ketika mereka pergi melalui pusat pengiriman internasional USPS. Saya mengesampingkannya dan mulai mencari salinan lain yang saya temukan bulan lalu. Dia tiba pada hari Jumat - dan saya segera mencoba merobeknya. Tetapi dengan mendorong dengan kesalahan yang sama persis . Tampaknya ini bukan masalah keausan atau kerusakan - disk mungkin keluar langsung dari pabrik.

TAMBAHAN: Setelah penyelidikan, saya tidak lagi percaya bahwa ini adalah cacat pabrik. Ketika saya menulis awal atau akhir trek yang buruk ke CD-R kosong dan menyalinnya, ripper menghasilkan kesalahan yang sama! Coba sendiri dengan file minimal.flac .

Ada dua opsi yang tersisa: coba suatu hari nanti untuk menemukan salinan lain yang akan berhasil disalin (tidak mungkin), atau entah bagaimana mengembalikan data suara asli dari disk yang rusak. Anda sudah tahu opsi mana yang telah saya pilih.

Bagaimana ripper bekerja

EAC tidak dapat membaca trek No. 3 dari disk [帰 る べ き 城]

CD menyimpan data digital, tetapi ada antarmuka yang sepenuhnya analog antara cakram, laser, dan dioda optik. Kesalahan membaca terjadi karena berbagai alasan: media kotor, goresan pada lapisan pelindung polycarbonate, getaran drive itu sendiri. Kode koreksi kesalahan primitif dalam standar CDDA membantu meminimalkan distorsi suara pada disk yang jarang digunakan, tetapi tidak dapat sepenuhnya memulihkan aliran bit pada CD dengan sejumlah besar kesalahan. Ripper modern memecahkan masalah dengan dua metode pendeteksian kesalahan yang penting: pembacaan berlebihan dan AccurateRip.

Halaman EAC: Extraction Technology menjelaskan bagaimana EAC menghasilkan pembacaan berlebihan:

Dalam mode aman, program membaca setiap sektor setidaknya dua kali [...] Jika terjadi kesalahan (baca atau sinkronkan), program akan terus membaca sektor ini hingga 8 dari 16 upaya identik. Prosedur semacam itu dilakukan paling banyak sekali, tiga atau lima kali (sesuai dengan kualitas pemulihan kesalahan yang dipilih). Jadi dalam kasus terburuk, bad sector dibaca 82 kali!

Semuanya sederhana. Jika permintaan baca terkadang mengembalikan data yang salah, baca lagi, dan kemudian berhati-hatilah jika dua yang pertama dibaca memberikan hasil yang berbeda. AccurateRip menggunakan prinsip yang sama, tetapi secara terdistribusi: ripper mengirim checksum dari file audio yang disalin ke layanan ini. Idenya adalah bahwa jika seribu orang menyalin trek dengan bit yang sama, ini mungkin rip yang tepat.

Artikel ini adalah tentang apa yang harus dilakukan jika kedua metode tidak dapat membantu. EAC tidak memberikan hasil jika setiap pembacaan mengembalikan data yang berbeda, dan dalam database AccurateRip hanya ada satu catatan tentang disk langka [1] .

"Aku melewati sepuluh ribu bagian, sepuluh ribu bagian untuk melihatmu"

Drive optik Asus, LG, Lite-On, Pioneer dan OEM yang tidak dikenal

Jika CD tidak disalin, logis untuk menggunakan drive yang berbeda. Terkadang model tertentu lebih merendahkan spesifikasi CDDA, atau apakah ada firmware yang lebih baik untuk memperbaiki kesalahan, atau yang lainnya. Forum DBpoweramp memiliki peringkat akurasi drive CD / DVD untuk memilih drive rip yang paling cocok.

Pada Sabtu pagi, saya membeli lima drive CD baru dari berbagai produsen [2] , Saya mencoba semuanya - dan menemukan satu yang dapat menjaga sinkronisasi pada beat beat. Sayangnya, konfirmasi rip tidak dapat diperoleh - di antara semua robekan ada sekitar 20.000 byte yang berbeda.

Tapi sekarang saya punya file .wav di disk, dan Anda bisa mendapat manfaat dari ini. Saya beralasan bahwa membaca kesalahan di jalur yang buruk berada di dekat yang "benar". Oleh karena itu, masuk akal untuk membuat beberapa robekan dan menemukan nilai "konsensus" untuk byte yang tidak stabil. Pendekatan ini pada akhirnya berhasil, tetapi membutuhkan lebih banyak pekerjaan daripada yang saya harapkan.

“Kuantitas masuk ke kualitas”

Saya mulai dengan menyalin disk beberapa kali pada salah satu drive, menulis semua nilai untuk setiap byte dan menyatakan kesalahan "dapat diperbaiki" jika lebih dari setengah robekan menghasilkan nilai byte spesifik untuk posisi ini. Permulaannya bagus: jumlah kesalahan yang tidak dapat diperbaiki menurun dari hampir ~ 6900 byte pada N = 4 hingga ~ 5000 byte pada N = 10. Manfaat dari setiap rip tambahan menurun dari waktu ke waktu, sampai sekitar N = 80 jumlah kesalahan yang tidak dapat diperbaiki menjadi stabil pada ~ 3700. Saya berhenti merobek N = 100.


Memperbaiki dan kesalahan fatal pada jumlah rip

Kemudian saya mencoba menyalin disk 100 kali pada drive kedua dan menggunakan dua kartu koreksi untuk "mengisi" posisi kesalahan yang tidak dapat diperbaiki dari drive pertama. Tapi itu tidak berhasil: pada setiap drive ada ribuan koreksi yang tidak sesuai dengan koreksi di yang lain! Ternyata noise tidak bisa dihilangkan dengan menggabungkannya dengan sumber noise lain yang terkait.


Hal yang sama, tetapi untuk dua disc lintas-validasi

Seni rakyat

Ada sumber daya lain yang baik di situs web EAC: tes kualitas DAE , yang menentukan kualitas firmware drive dengan tingkat kesalahan yang diperbaiki. Ini adalah penanganan kesalahan level yang lebih rendah ketika drive mengoreksi kesalahan baca daripada hanya melaporkannya. Tangkapannya adalah bahwa "safe mode" dari EAC hanya tersedia ketika Anda menonaktifkan kode koreksi kesalahan bawaan ini, menunjukkan bahwa itu tidak bekerja dengan benar.

Saya menyiapkan tes dengan membakar file .wav ke CD-R, menyoroti sektor yang tepat di permukaan data dan dengan hati-hati mengecatnya dengan spidol hitam. Ini dijamin kesalahan fatal pada pola deterministik.

Saya menguji semua drive dan mendapat dua hasil menarik:



Saya menggunakan drive Lite-On untuk mengatasi kesalahan sinkronisasi. Dia mengunyah penanda ajaib dengan senang, tetapi dia sangat bingung dengan garis lurus di permukaan data. Anda dapat melihat bagaimana alih-alih tiga puncak terpisah di sebelah kanan ada satu gumpalan gagal besar.

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)



Drive Pioneer menerima skor DAE tertinggi. Menurut pendapat saya, bagan tidak terlihat istimewa, tetapi alat analisis mengatakan bahwa ini adalah firmware terbaik untuk memperbaiki kesalahan dalam set kecil saya.

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)

"Dari saat tertentu, angka penting"

Bagaimana cara menggunakan firmware Pioneer dengan koreksi kesalahan yang baik jika "safe mode" EAC mengabaikannya? Sangat sederhana: alihkan EAC ke "burst mode" dan tulis ke disk bit stream dalam bentuk di mana firmware melaporkannya. Lalu bagaimana mengubah sekelompok file .wav yang tidak diverifikasi ini menjadi file berkualitas baik, seperti dalam "safe mode"? Ya, alat analisis kesalahan yang sama yang kami gunakan dalam robekan dengan Lite-On!

Setelah beberapa pengaturan konfigurasi EAC dan setelah seratus robekan, kami mendapatkan diagram yang begitu indah.


Memperbaiki dan memperbaiki kesalahan pada jumlah robekan (Pioneer)

Apa yang bisa dicatat:

• Kesalahan bit fatal cepat cenderung ke nol, tetapi tidak pernah mencapainya.
• Lompatan besar dalam bug yang diperbaiki dalam 53-54 robekan.
• Jumlah kesalahan sebelum dan sesudah lompatan besar ini praktis tidak berubah, yang menunjukkan bidang stabilitas dalam data yang disalin.

0xA595BC09

Menggunakan koreksi kesalahan yang hampir sempurna dari Pioneer, saya menghasilkan file "tebakan terbaik" dan mulai membandingkannya dengan robekan Pioneer. Seperti yang diharapkan, beberapa bagian berkualitas rendah ditemukan, yang saya koreksi dengan membuat 10 robekan lagi:

$ 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

Saya juga menemukan sesuatu yang sangat menarik: beberapa robekan menghasilkan konten yang persis sama! Ingat, ini justru kriteria untuk sukses dalam "safe mode" EAC. shncat -q -e | rhash --print="%C" shncat -q -e | rhash --print="%C" digunakan untuk menghitung checksum CRC32 dari data audio mentah: inilah yang digunakan 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
[...]

Sementara itu, robekan berulang dari bagian berkualitas rendah memungkinkan kami untuk menyelesaikan analisis dengan nol kesalahan fatal. Dan ketika saya memeriksa file ini, ada konten audio yang persis sama seperti pada rip "biasa"! Ini cukup untuk menyatakan kemenangan.

Saya 99% yakin bahwa saya berhasil menyalin CD bermasalah ini, dan 0xA595BC09 adalah jumlah CRC yang tepat untuk track nomor 3.

Lampiran A: compare.rs

Saya menggunakan alat ini untuk menghitung kemungkinan byte error. Ini tidak dimaksudkan untuk penggunaan jangka panjang, jadi ini sedikit jelek, tetapi mungkin menarik bagi mereka yang menemukan halaman ini, menyelesaikan masalah yang sama.

 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. Dalam catatan AccurateRip tunggal ini, CRC untuk semua trek kecuali nomor trek 3 cocok dengan disk saya: jumlahnya adalah 0x84B9DD1A, dan saya punya 0xA595BC09. Saya menduga bahwa ripper tidak mengerti bahwa ia memiliki drive yang buruk. [kembali]

2. Pertanyaan yang jelas ketika membeli drive CD atau DVD pada tahun 2018 adalah: "Sial, di mana saya bisa membelinya?" Dan saya tidak membutuhkan satu, tetapi beberapa dari merek yang berbeda . Saya tahu hanya satu toko di dekatnya yang memiliki drive DVD 5,25 ". Hanya satu toko yang cukup besar untuk tidak menyesali ruang rak untuk drive seperti itu, dan cukup aneh untuk tidak terlihat aneh di sana. Tentu saja, saya berbicara tentang Frys Electronics. [kembali]