Chất lượng đĩa CD chép có làm khác âm thanh không

E cũng lăn tăn và tìm đọc nhiều bài viết cả Tây lẫn ta về so sánh giữa CD F0 và F1 mà chưa ngã ngũ. T6 tuần trước có chút thời gian và công cụ ngồi làm 1 thử nghiệm nho nhỏ nên xin phép post lên thread này gọi là mua vui cho ae hihi

Hoàn cảnh:
Em có chơi cả CD F0 và F1. CD F1 thì có 1 số là e mua của shop, 1 số là tự ghi bằng ổ ghi của laptop (dùng file nrg down từ diễn đàn hdvietnam là chính).

Tiến hành:
E dùng phần mềm để đối chiếu độ động (dynamic range) của đĩa F0 và F1 của cùng 1 albumn.

Phần mềm sử dụng:
+) Rip file nhạc từ đĩa CD: Exact audio copy
+) Đo độ động: TT DR tải từ trang Album list - Dynamic Range DB (loudness-war.info). Trang này là cộng đồng của bọn Tây chia sẻ thông số về độ động của các album (do bọn nó muốn để lại di sản cho con cháu biết về loudness war ) và dân chơi trước khi mua cũng tránh mua albumn nào bị nén (compressed) nhiều quá)

Kết quả
+) Albumn Hoàng Nhật Minh acoustic của Class A recording (CD này F1 được e tự burn từ file nrg rip từ F0): độ động của F0 và F1 là hoàn toàn giống hệt nhau.

+) Albumn Paint my love của Michael learns to rock (CD này F1 mua của shop): độ động của F1 kém hơn 1 chút so với F0

Suy nghĩ chủ quan của cá nhân:
Sau khi làm thí nghiệm xong thì em tạm kết luận là F0 và F1 xác suất cao là sẽ có sự khác biệt vì trừ khi mình burn nguyên bản bằng file nrg rip từ F0 ra thì chắc chắn sẽ có sự khác biệt. Ngoài ra đĩa F0 chất lượng phôi cũng tốt hơn nên nhiều khả năng F1 xịn (burn từ nrg của F0) sau khi qua sử dụng 1 thời gian dài thì phôi đĩa sẽ có suy hao dẫn đến chất lượng âm thanh thay đổi.

Tâm sự ngoài lề:
Em cũng chỉ là 1 người chơi, có chút thời gian thì nghịch ngợm chút chứ không có ý công kích người chơi F1 hay shop bán F1 ạ (vì bản thân e cũng mua và chơi F1 ) nên mong bài viết không hợp mắt ai thì các bác dơ cao đánh khẽ. Em cũng có đo đạc độ động F0 của 1 số albumn bên Audiospace phát hành mà không tiện chia sẻ trong khuôn khổ của bài viết, ae nào hứng thú xem kết quả thì inbox kín ạ.
Ngoài ra, e mong Mod mở lòng từ bi cho phép em được đăng hình trong chuyên mục mua bán để thi thoảng em được giao lưu đồ chơi mới dễ dàng hơn ạ. Em xin hứa sẽ ngoan ạ

 

Em hỏi ngoài lề 1 chút: Em đang có kế hoạch rip tất cả số CD F0 và F1 mình có vào PC để nghe cho tiện và lưu trữ đề phòng CD hỏng (một số chiếc đã có dấu hiệu mốc và vấp). Em định sẽ lưu trữ các CD files này vào ổ cứng di động. Vậy trong quá trình rip, để có chất lượng âm thanh tốt nhất thì file audio nên lưu vào ổ NVME cắm trong máy rồi sau đó copy sang ổ cứng di động hay rip thẳng vào ổ cứng di động ạ. Mong nhận được tư vấn của các bác. Em xin cảm ơn!

 

@CADIC1008 an toàn thì nên rip vào ổ cứng cắm trong máy rồi copy ra ổ di động sau ạ. E đã từng bị trường hợp rip thẳng ra ổ cứng di động thì chẳng may chạm tay vào dây nối, mất kết nối ổ cứng di động đột ngột làm hỏng file và sau đó đĩa bị hỏng mất cái bài đang rip dở lúc đó ạ

 

Bác đã quan tâm đến mức này thì phải tự làm trải nghiệm thôi bác. Đến giờ em vẫn chưa tìm được cách rip ra file lẻ ổn nhất.

Bác cần quan tâm đến các điều sau:
① Chương trình rip, mỗi chương trình rip cho âm thanh khác nhau và thông thường là dở hơn nghe trực tiếp từ đĩa. Có chương trình EAC rip ra file wav+cue là ổn nhất nhưng lại bị nhược điểm là 1 file cho toàn bộ đĩa, không phải chương trình nghe nhạc nào cũng hỗ trợ đọc thông tin từ file cue.
② Thời điểm rip, chất lượng điện nguồn từ lưới ảnh đến âm thanh của file kết quả rip. Do vậy chọn giờ có điện nguồn tốt để thực hiện, ví dụ giữa trưa hay nửa đêm
③ Thiết bị rip: mỗi máy tính đều rip cho âm thanh khác nhau. Giống như thiết bị audio vậy.
④ Chống rung cho máy tính hay ổ đĩa cũng ảnh hưởng đến âm thanh của file rip.
⑤ Lưu trữ file vào ổ đĩa khác nhau sẽ cho âm thanh khác nhau: do vậy nên lưu vào nvme thì tốt hơn ổ cứng di động.
⑥ Thời điểm copy từ nvme sang ổ di động khác nhau cũng cho âm thanh khác nhau, do ảnh hưởng của chất lượng nguồn điện. Cái này khó phân biệt nên nếu không phân biệt nổi thì bỏ qua cũng được.
⑦ Việc thêm meta data (tag) vào file có sẵn cũng gây thay đổi chất âm.
⑧ Chọn lựa file flac hay wav hoặc thay đổi các kiểu nén flac (codec) cũng gây thay đổi âm thanh.

Trong các yếu tố trên thì yếu tố ①, ②, ⑦, ⑧ ảnh hưởng mạnh nhất. Do vậy, bác cần thử nghiệm kỹ lưỡng mới xác định được app vừa ý với mình và tốt nhất là chưa nên thanh lý đống CD cho đến khi bác thực sự vừa ý với bản rip.

 

Cùng một soft để convert nhưng version khác nhau cũng cho ra 2 sp khác nhau.

 

Vâng bác! Cùng một soft, cùng một phiên bản nhưng setting khác nhau thì cũng cho âm thanh khác nhau. Mà đau cái là cái setting đó nhiều khi chẳng liên quan méo gì đến âm thanh nhưng nó cũng ảnh hưởng đến chất âm của file thành quả. Nhức đầu lắm

 

@quocdat Em đã đọc đi đọc lại chỉ dẫn của bác. Thật sự những điều đó là rất quý báu đối với em. Em chân thành cảm ơn bác và chúc bác nhiều sức khỏe và niềm vui.
Trân trọng.

 

Vâng bác! Hy vọng bác tìm ra cách rip cho âm thanh vừa ý.
Em lưu ý với bác một điều nữa ở ý ① ở trên do em viết chưa đủ: EAC có lựa chọn rip wav+cue (1 file cho toàn đĩa) và wav lẻ (mỗi bài một file) thì chỉ có wav+cue mới cho âm thanh đủ hay, còn tách ra file lẻ thì âm thanh không hay (dù vẫn dùng chính EAC thực hiện).
Ngoài ra còn một lưu ý nữa: việc phân biệt chất lượng âm thanh giữa các kiểu rip theo những note em đã nói ở trên không dễ phân biệt được, nếu bác thử một vài lượt mà không phân biệt được thì không cần lấn cấn gì những điều em nêu ở trên cứ rip rồi nghe thôi.

 

Lý thuyết: cùng 0, 1 như nhau.
Thực tế: nghe khác, xịn hay hơn. Bác nào không thấy khác thì xin chúc mừng, đỡ tốn tiền

 

Tai nghe được chúc mừng tai không nghe được chỉ vì đỡ tốn tiền… vui nhỉ.

 

Đọc hết nhưng chưa thấy ai nói đủ các ý. Nhiều ý kiến vẫn đang loanh quanh bằng mấy từ google được như là check-sum, file correct,... nhưng em hỏi thật có bác nào thực sự hiểu các method này?
Em là dân lập trình, vậy em sẽ viết về lập trình để các bác có thêm thông tin - anh em nào trong nghề có thể bổ sung.
Check-sum hiểu đơn giản là 1 phương thức, thuật toán, có thể triển khai ở nhiều ngôn ngữ từ C đến Java hay các Framework cao hơn đều có thể viết được.
Ví dụ trong Java, nó là một kỹ thuật phát hiện lỗi có thể được áp dụng cho gói tin (message) có độ dài bất kỳ.
Nó được sử dụng chủ yếu ở các lớp mạng và vận chuyển của bộ giao thức TCP / IP.
Ở đây, chúng tôi đã xem xét dữ liệu thập phân đang được người gửi gửi đến người nhận qua các port.
Số lượng "mảnh dữ liệu" (packages) mà dữ liệu được chia thành ở đây phụ thuộc vào độ dài dữ liệu được gửi.
Nếu độ dài của dữ liệu được gửi là 'x', thì số lượng "mảnh dữ liệu" cũng là 'x', tức là mỗi "mảnh dữ liệu" có dữ liệu duy nhất. Ở đây, về cơ bản chúng ta xử lý dữ liệu thập phân.
Khái niệm này cũng sẽ nhất quán đối với dữ liệu chuỗi vì mỗi ký tự của chuỗi có thể được biểu diễn bằng mã ASCII tương đương của nó, do đó một lần nữa để lại cho chúng ta dữ liệu thập phân.

Ví dụ 1 hàm đơn giản cho output như sau:

Code:

At sender side :
Enter data length
4
Enter data to send
67
43
0
22
Checksum Calculated is : 90
Data being sent along with Checksum.....
Thanks for the feedback!!
Message received Successfully!
At receiver side :
Data received (along with checksum) is
67
43
0
22
90
Sum(in ones complement) is : 127
Calculated Checksum is : 0

Here the checksum calculated at
the receiver side was 0. Hence,
it indicates a successful data transfer.

Vậy chúng ta hiểu sâu về bản chất vòng lặp của việc gửi nhận này sẽ được lặp lại cho tới khi đạt mức Checksum quy định. Nhưng - CD là 1 đối tượng vật lý, nó có những hư hại vật chất khiến mắt quang ko thể đọc được.
Vấn đề ở đây sẽ là:
1.
Mắt đọc trên đầu CD Read không đọc chính xác dữ liệu trên đĩa CD master. Điều này hoàn toàn xảy ra vì khi đĩa bẩn, đĩa mờ, đĩa xước - Với dữ liệu gốc là 1001 nhưng sensor đọc lần 1 lại ra 1100. Checksum ở đây ví dụ = 90.
Ở bộ nhớ đệm trên CDP, nhận tín hiệu đầy đủ là 1100 với checksum = 90 => Chip DAC tiếp tục giải mã ra tín hiệu Analog mà ko cần lặp lại quá trình này.

2.
Với dữ liệu gốc là 1001 nhưng sensor đọc lần 1 lại ra 1100. Checksum ở đây ví dụ = 90.
Ở bộ nhớ đệm trên CDP, nhận tín hiệu lại là 1000. Checksum = 89 (sai) => Quá trình repeat được gọi , lấy lại cho tới 1 ngưỡng giới hạn nào đó trong khung thời gian thực (bộ đệm buffer).
- Nếu lấy lại được đúng, quy trình 1. tiếp tục.
- Nếu mãi ko lấy lại được, buffer đầy, thì nó sẽ dùng nội suy để dự đoán hoặc by pass - lúc này sẽ bị đứt gãy âm thanh.

Dễ dàng nhận thấy, việc mắt đọc có đọc được chính xác 1 - 1 nội dung trên đĩa gốc phụ thuộc vào chất lượng mắt, chất lượng phôi (các thông tin checksum được embed cùng đĩa, thậm chí có nhiều hãng in 2 lớp, 3 lớp để khi sự cố error xảy ra, thì cũng có nơi để mà quét lại dữ liệu cho chuẩn).
Với đĩa RIP, có 2 hạn chế:
1 là: Nội dung được RIP vào đó có thể không phải là 1 - 1 với CD gốc. Nên nhớ rằng cho dù check-sum bằng nhau, dữ liệu trên đó chưa chắc đã bit perfect vì quá trình đọc là 1 quá trình quang học-data.
2 là: Quá trình re-call data từ buffer mem cache đến sensor là CÓ HẠN, ko phải lặp vô tận. Đến ngưỡng nào đó sẽ phải đẩy tín hiệu vào chip DAC trong khung thời gian Clock. Quá trình đẩy data vào chip DAC là realtime (hoặc near realtime) với các chuẩn asyn, syn (đồng bộ, bất đồng bộ).

Tổng kết:
Sẽ không bao giờ đạt được trạng thái 1-1 khi sao chép dữ liệu qua CD. Vì đó là quá trình quang học - điện tử.
Mở rộng thêm, với 2 chip bán dẫn hiện đại để lưu dữ liệu. Nếu tìm hiểu sâu về bản chất vì sao transitor lưu trữ được điện áp & coi đó là 1 hay 0, thì cũng dễ hiểu 1 điều không có gì là vĩnh cửu, transitor đó ko thể mãi mãi tồn tại ở trạng thái 0 hoặc 1 (nếu bị suy giảm điện áp, sai lệch cơ học bán dẫn) thì việc hỏng dữ liệu hoàn toàn xảy ra.

Quá trình checksum nó là 1 thuật toán xưa như trái đất, như trình bày ở trên, checksum lấy giá trị tổng hợp của 1 nhóm dữ liệu. Với 2 string (Chuỗi) dữ liệu có checksum bằng nhau vẫn ko đảm bảo 2 dữ liệu đó value bằng nhau tuyệt đối.

Trong lập trình nhúng cho các DAC, CDP, không ai đặt trạng thái bắt buộc để đi tiếp là SUM == 0 như ví dụ ở dưới đâu các bác:

Code:

// Opens a socket for connection
        s = new Socket(ip,port);
     
        dis = new DataInputStream(s.getInputStream());
        dos = new DataOutputStream(s.getOutputStream());
     
        while (true)
        {   Scanner sc = new Scanner(System.in);
            int i, l, nob, sum = 0, chk_sum;
         
            // Reads the data length sent by sender
            l = dis.readInt();
         
            // Initializes the arrays based on data length received
            int c_data[] = new int[l];
            int data[] = new int[l];
         
            System.out.println("Data received (along with checksum) is");
         
            for(i = 0; i< data.length; i++)
            {
                // Reading the data being sent one by one
                data[i] = dis.readInt();
                System.out.println(data[i]);
             
                // Complementing the data being received
                nob = (int)(Math.floor(Math.log(data[i]) / Math.log(2))) + 1;
                c_data[i] = ((1 << nob) - 1) ^ data[i];
             
                // Adding the complemented data
                sum += c_data[i];
            }
            System.out.println("Sum(in ones complement) is : "+sum);
         
            // Complementing the sum
            nob = (int)(Math.floor(Math.log(sum) / Math.log(2))) + 1;
            sum = ((1 << nob) - 1) ^ sum;
            System.out.println("Calculated Checksum is : "+sum);
         
            // Checking whether final result is 0 or something else
            // and sending feedback accordingly
            if(sum == 0)
            {
                dos.writeUTF("success");
                break;
            }  
            else
            {
                dos.writeUTF("failure");
                break;
            }
        }
     
        // Closing all connections
        dis.close();
        dos.close();
        s.close();
    }

 

Em thì không thuộc ngành IT, nhưng em cũng hiểu F1,2…n không thể bằng Fo được. Còn vì sao, em không biết. Qua phân tích chuyên ngành của bác chắc AE cũng hiểu thêm chút. Em chỉ là người “nghe lóm”. Còn các bác cứ nói F1,2…giống Fo thì em cũng xin chúc mừng.

 

Thật ra em ko biết giải thích đâu nhưng về mặt dữ liệu thì việc “nước trong quá thì không có cá”. Ý là nếu gắt gao việc check đầy đủ dữ liệu quá thì sẽ bị tác hại là nghe sẽ cà dựt, dân dã hay còn gọi là kén đĩa. Nên NSX hay kỹ sư sẽ cân đối con số này trong lập trình. Các thuật toán nội suy, by pass sao cho hay lại là 1 phạm trù khác.

 

E thì không biết KT, nhưng nghe lỏm thì thấy bảo có thuật nội suy, nếu vô tình mất bit nào nó cũng nội suy ra dc tuy nhiên sẽ hổng giống cũ. Ngoài ra tia laser khi phản xạ về phần thu giữa phôi xịn và copy cũng sẽ hao hụt khác nhau,… nói chung là e nghe thấy nó khác. Còn bác nào không thấy khác thì sẽ cho rằng không khác. Tranh luận cả đời không kết thúc.

 

Vì là diễn đàn công nghệ, nên em tiếp tục nói tới thuật toán nội suy.

Thuật toán này - cũng XƯA như trái đất và là thuật toán rất cơ bản không có gì ... đáng sợ.
Nội suy là gì, nội suy có nghĩa là suy diễn từ 1 cái có sẵn (nội).
Các bước triển khai thuật toán tìm kiếm nội suy cơ bản:

Bước 1: Xác định phần tử trung bình
Đầu tiên, ta cần xác định phần tử trung bình trong mảng. Phần tử này có thể được xác định bằng cách sử dụng công thức sau:
mid = low + ((key - arr[low]) * (high - low)) / (arr[high] - arr[low]).
Trong đó, key là giá trị cần tìm, arr là mảng đã sắp xếp, low là chỉ số của phần tử đầu tiên và high là chỉ số của phần tử cuối cùng.
Ánh xạ ra, nếu biết trước 2 note nhạc, muốn tìm giá trị note giữa 2 note đó để "làm mềm" thì ta tạo ra 1 giá trị trung bình.

Bước 2: Kiểm tra phần tử trung bình
Sau khi xác định phần tử trung bình, ta cần kiểm tra xem phần tử này có phải là phần tử cần tìm hay không. Nếu đúng, trả về chỉ số của phần tử đó, rồi đi tới bước 5.
Ở bước này, mỗi lần nội suy, ta sẽ compare với giá trị checksum như em vừa trình bày ở comment trên - bao giờ kết quả ở mức CHẤP NHẬN ĐƯỢC theo ông lập trình đã đặt ra thì sẽ chọn giá trị nội suy đó.

Bước 3: So sánh phần tử trung bình với giá trị cần tìm

Bước 4: Lặp lại quá trình cho đến khi trả về kết quả tìm kiếm
Tiếp tục lặp lại quá trình trên cho đến khi tìm được phần tử cần tìm hoặc khi không tìm thấy phần tử đó.

Bước 5: Kết thúc. Chấp nhận kết quả nội suy như là 1 kết quả bảo toàn.

Nói đến đây, chắc các bác biết được rằng bằng lập trình, bằng cơ lý bán dẫn - ta có thể khẳng định được việc checksum - nội suy - bảo toàn dữ liệu là thế nào và tự có câu trả lời cho mình rồi đúng ko ạ.

Một số thuật toán Nội suy nâng cao, đôi khi ... hay hơn cả file gốc (méo) thì nó lại đi đến kết luận là file copy hay hơn. Tương tự như việc upsampling vậy.

 

Cái mà hay hơn file gốc thì có lẽ do file gốc làm sai, nó lấy mẫu nội suy “may mắn” “chỉnh” lại đúng thôi bác ơi. Chứ theo xxx ý của em ví dụ như này cho dễ hiểu, chén nước đổ ra thì bác có cách nào thu hết lại được không???

 

Đầy cụ chơi chỉnh EQ cho méo hết sai với âm gốc nhưng gật gù khen hay ạ. Nên em chém gió về mặt kỹ thuật còn gu nghe thì ko dám chê. Em đến nhiều nhà các bác chơi CD chép nhưng vẫn chắc như đinh đóng cột là CD anh chép hay hơn cả gốc
Với công nghệ bây giờ, nhiều bản thu gốc đã lỗi, phô, có khi xài AI nó sửa được cho hay hơn ấy chứ.

 

Đĩa F0,F1… nó có khác nhau hay ko thì lại phải phụ thuộc vào bộ dàn âm thanh có đủ để phát ra sự khác biệt ko. Hazzz

 

Nếu đánh giá F0, F1 mà có cả yếu tố: phải phụ thuộc vào bộ dàn âm thanh có đủ để phát ra sự khác biệt… thì tôi thấy cần phải đưa thêm yếu tố: cho dù dàn âm thanh có đủ để phát ra sự khác biệt mà chủ nhân không phân biệt được chứ nhỉ…
Chỉ vì cái sự nghe: có- không, tai rơi- tai chuột, tôi không thấy khác ông thấy khác thì ông phải có trách nhiệm chứng minh… v.v. Cuối cùng câu chuyện nào cũng dẫn đến ngày xưa à. Chán.

 

Mình Trả lời dựa theo kinh nghiệm thực chứng. Từng chơi và đang chơi.
Có khác. Khác nhiều là đằng khác. Nhưng hay hơn hay dở hơn thì còn tùy vào thiết bị rip, thiết bị ghi, kỹ thuật rip, kỹ thuật ghi.
Mình khuyên anh em muốn tìm câu trloi hãy tự học hỏi và trải nghiệm. Đừng quan tâm dư luận vì đa số là comment của dân chưa biết chơi.

 

Cơ bản là dùng soft để ktra thấy nó hoàn toàn giống nhau ở phần "digital file" chứ không phải CD (phôi) nhưng khi nghe thấy nó vẫn khác. Còn "hay" hay "dở" tùy vào quan điểm nghe: có người nghe MP3 hay hơn CD, CD hay hơn LP, ... là bình thường. Chỉ nên tập trung tìm hiểu để đi đến kết luận nó "khác nhau" bác nhỉ. Vậy thôi.

 

Chép CD thì máy tính nhớ nối đất nhé các cụ, thiếu dây GND thì hầu như là CD chép khó mà nghe ổn được. Các cụ thử chép CD qua phần mềm Ashampoo Burning Studio (Free 100%) - Dân Đức làm phần mềm không tệ chút nào.