Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: CDs with different offsets encode to MP3 differently? (Read 5115 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CDs with different offsets encode to MP3 differently?

I have two pressings of Dido's No Angel, one in jewel case, and the other in digipack format. I ripped them in EAC (CUE + Image) and compared them with CUETools, and these two pressings just differed by an offset of 676.

I encoded them with MP3, and by looking at the track peaks in foobar, the resultant MP3 files between the two pressings are different.
I even tried encoding the album as a single track, and the track peaks differed from the original encodings as well. This is a screenshot of the MP3 data from foobar.



I have tried re-encoding all the files, and the results are consistent, i.e. encoding the digipack version twice produces the same MP3s with the same peaks.

I also have two pressings of 'The Best of Kansas' with just an offset difference as well, and the MP3s were also encoded differently for the two pressings with different track peaks.

So is this normal behaviour?



The following are EAC and CUETools log to confirm that they just differ in offset.

Jewel Case Pressing EAC Log

Code: [Select]
Exact Audio Copy V0.99 prebeta 4 from 23. January 2008

EAC extraction logfile from 5. January 2009, 23:44

Dido / No Angel

Used drive  : HL-DT-STDVD-ROM GDR8161B   Adapter: 1  ID: 1

Read mode : Burst

Read offset correction                      : 102
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks   : No
Null samples used in CRC calculations       : Yes
Used interface                              : Installed external ASPI interface

Used output format              : User Defined Encoder
Selected bitrate                : 896 kBit/s
Quality                         : High
Add ID3 tag                     : No
Command line compressor         : C:\Program Files\FLAC\flac.exe
Additional command line options : -V -8 -T "artist=%a" -T "album=%g" -T "date=%y" -T "genre=%m" -T "comment=%e" %s


TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  |  0:00.00 |  4:15.30 |         0    |    19154   
        2  |  4:15.30 |  3:57.17 |     19155    |    36946   
        3  |  8:12.47 |  4:32.28 |     36947    |    57374   
        4  | 12:45.00 |  4:27.67 |     57375    |    77466   
        5  | 17:12.67 |  3:53.58 |     77467    |    94999   
        6  | 21:06.50 |  3:38.27 |     95000    |   111376   
        7  | 24:45.02 |  4:38.58 |    111377    |   132284   
        8  | 29:23.60 |  4:52.15 |    132285    |   154199   
        9  | 34:16.00 |  3:54.07 |    154200    |   171756   
       10  | 38:10.07 |  3:55.45 |    171757    |   189426   
       11  | 42:05.52 |  3:09.53 |    189427    |   203654   
       12  | 45:15.30 |  6:42.55 |    203655    |   233859   
       13  | 54:30.10 | 16:12.22 |    245260    |   318181   


Range status and errors

Selected range

     Filename C:\Album Art\Dido - No Angel.wav

     Peak level 100.0 %
     Copy CRC D8989EA6
     Copy OK

No errors occurred

 
AccurateRip summary
 
Track  1  accurately ripped (confidence 28)  [74541A60]
Track  2  accurately ripped (confidence 28)  [6C79B651]
Track  3  accurately ripped (confidence 28)  [F485620C]
Track  4  accurately ripped (confidence 28)  [06C0DEE7]
Track  5  accurately ripped (confidence 26)  [83D1BBDD]
Track  6  accurately ripped (confidence 27)  [15090978]
Track  7  accurately ripped (confidence 27)  [9EEC58A7]
Track  8  accurately ripped (confidence 28)  [C9AA9625]
Track  9  accurately ripped (confidence 26)  [2C392C15]
Track 10  accurately ripped (confidence 27)  [42164BAC]
Track 11  accurately ripped (confidence 28)  [81E6FAA7]
Track 12  accurately ripped (confidence 24)  [A1F54607]
 
All tracks accurately ripped

End of status report

Digipack Pressing EAC Log

Code: [Select]
Exact Audio Copy V1.0 beta 3 from 29. August 2011

EAC extraction logfile from 4. June 2013, 21:59

Dido / No Angel

Used drive  : HL-DT-STDVD-ROM GDR8161B   Adapter: 1  ID: 0

Read mode : Burst

Read offset correction                      : 102
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks   : No
Null samples used in CRC calculations       : Yes
Used interface                              : Native Win32 interface for Win NT & 2000

Used output format              : User Defined Encoder
Selected bitrate                : 1024 kBit/s
Quality                         : High
Add ID3 tag                     : No
Command line compressor         : C:\Program Files\Exact Audio Copy\Flac\flac.exe
Additional command line options : -8 -V -T "ARTIST=%artist%" -T "ALBUM=%albumtitle%" -T "DATE=%year%" -T "GENRE=%genre%" -T "COMMENT=%comment%" -T "COMPOSER=%composer%" -T "TOTALTRACKS=%numtracks%" %source% -o %dest%


TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  |  0:00.00 |  4:15.30 |         0    |    19154   
        2  |  4:15.30 |  3:57.17 |     19155    |    36946   
        3  |  8:12.47 |  4:32.28 |     36947    |    57374   
        4  | 12:45.00 |  4:27.67 |     57375    |    77466   
        5  | 17:12.67 |  3:53.58 |     77467    |    94999   
        6  | 21:06.50 |  3:38.27 |     95000    |   111376   
        7  | 24:45.02 |  4:38.58 |    111377    |   132284   
        8  | 29:23.60 |  4:52.15 |    132285    |   154199   
        9  | 34:16.00 |  3:54.07 |    154200    |   171756   
       10  | 38:10.07 |  3:55.45 |    171757    |   189426   
       11  | 42:05.52 |  3:09.53 |    189427    |   203654   
       12  | 45:15.30 |  6:42.55 |    203655    |   233859   
       13  | 54:30.10 | 16:12.22 |    245260    |   318181   


Range status and errors

Selected range

     Filename C:\EAC Temp\Dido - No Angel.wav

     Peak level 100.0 %
     Extraction speed 26.0 X
     Copy CRC B351B55F
     Copy OK

No errors occurred

 
AccurateRip summary
 
Track  1  accurately ripped (confidence 4)  [5AC20299]  (AR v2)
Track  2  accurately ripped (confidence 4)  [19C06DDA]  (AR v2)
Track  3  accurately ripped (confidence 4)  [7A8A4581]  (AR v2)
Track  4  accurately ripped (confidence 4)  [7049354B]  (AR v2)
Track  5  accurately ripped (confidence 4)  [DBAC2EF5]  (AR v2)
Track  6  accurately ripped (confidence 4)  [A6CA129D]  (AR v2)
Track  7  accurately ripped (confidence 4)  [F8C4949D]  (AR v2)
Track  8  accurately ripped (confidence 4)  [83AD6524]  (AR v2)
Track  9  accurately ripped (confidence 4)  [28133EAA]  (AR v2)
Track 10  accurately ripped (confidence 4)  [CA7E56E8]  (AR v2)
Track 11  accurately ripped (confidence 4)  [83CC847E]  (AR v2)
Track 12  accurately ripped (confidence 4)  [2B2148B9]  (AR v2)
 
All tracks accurately ripped

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: eYsjUXIwOHyLD6N4RGuB6yZv2Mw-] found, Submit result: eYsjUXIwOHyLD6N4RGuB6yZv2Mw- has been confirmed
[b69dda21] (533/565) Differs in 9337 samples @00:01:09-00:01:61,00:03:54-00:03:57
[790ef625] (017/565) Accurately ripped
[f1d84e0a] (001/565) No match
[dc65cd46] (001/565) No match
[c0b96b2a] (001/565) No match
[a03d86bf] (001/565) No match
[d3f6f4d0] (001/565) No match
[73f89daf] (001/565) No match
[02a3a9ce] (001/565) No match
[ee6c5c66] (001/565) No match
[b9073592] (001/565) No match
[85d50d8d] (001/565) No match
[3ef4ea9b] (001/565) No match
[0ddb999e] (001/565) No match
[236c3dad] (001/565) No match
[e96f3f61] (001/565) No match
[08c78c21] (001/565) No match
You can use CUETools to repair this rip.


==== Log checksum E1083EE72765E8CD94DC20E8E238CCA42A604FCEDF6B476795723E09A03262E5 ====

The following is a truncated CUETools log, and I have highlighted the different pressings.

Code: [Select]
[AccurateRip ID: 0017e86b-00e403df-c210920d] found.
Track   [  CRC   |   V2   ] Status [color=#FF0000][b]DIGIPACK PRESSING[/b][/color]
 01     [a47b8ca5|5ac20299] (024+004/567) Accurately ripped
 02     [ec633cec|19c06dda] (024+004/566) Accurately ripped
 03     [555ab5fd|7a8a4581] (024+004/564) Accurately ripped
 04     [5b031f38|7049354b] (024+004/566) Accurately ripped
 05     [2e0dc5bd|dbac2ef5] (024+004/564) Accurately ripped
 06     [34d84e05|a6ca129d] (024+004/565) Accurately ripped
 07     [c54cb582|f8c4949d] (024+004/563) Accurately ripped
 08     [806cdb98|83ad6524] (024+004/563) Accurately ripped
 09     [deb356fa|28133eaa] (024+004/562) Accurately ripped
 10     [35391615|ca7e56e8] (024+004/564) Accurately ripped
 11     [eb1250ac|83cc847e] (024+004/561) Accurately ripped
 12     [2bde778f|2b2148b9] (024+004/554) Accurately ripped

Offsetted by 676: [color=#FF0000][b]JEWEL CASE PRESSING[/b][/color]
 01     [74541a60] (039/567) Accurately ripped
 02     [6c79b651] (039/566) Accurately ripped
 03     [f485620c] (039/564) Accurately ripped
 04     [06c0dee7] (039/566) Accurately ripped
 05     [83d1bbdd] (038/564) Accurately ripped
 06     [15090978] (039/565) Accurately ripped
 07     [9eec58a7] (038/563) Accurately ripped
 08     [c9aa9625] (038/563) Accurately ripped
 09     [2c392c15] (035/562) Accurately ripped
 10     [42164bac] (038/564) Accurately ripped
 11     [81e6faa7] (039/561) Accurately ripped
 12     [a1f54607] (036/554) Accurately ripped

This is a screenshot of the EAC Compare WAV to determine that the 2 wave files are really just an offset, with no data differences. They have the same length as well.

CDs with different offsets encode to MP3 differently?

Reply #2 –
Quote from: greynol on
Yes, this is perfectly normal.

The encoder is working with frames of different data, so different output should be expected.


Thanks for the assurance that it's normal, but I don't understand your explanation.
Only the first 676 samples are different, so at most, only the first track would be affected? No?

CDs with different offsets encode to MP3 differently?

Reply #4 –
If 676 samples were an exact multiple of one frame of data in mp3 then it is conceivable that virtually the entire file would be identical, but this is not the case.

CDs with different offsets encode to MP3 differently?

Reply #5 –
Quote from: greynol on
No. All data is shifted by the offset so all frames with non-null data as split by the encoder will be different.


So the main difference is just that the songs are split at different points?

In that case, wouldn't the overall album peak of the MP3s of both pressings be the same? In the above situation. The digipack MP3s has an overall peak of 1.158, while the jewel case has an overall peak of 1.136.

And the single track image MP3s have different peaks altogether.

CDs with different offsets encode to MP3 differently?

Reply #6 –
Quote from: pdq on
If 676 samples were an exact multiple of one frame of data in mp3 then it is conceivable that virtually the entire file would be identical, but this is not the case.


Ok got it, thanks for your help!
 

CDs with different offsets encode to MP3 differently?

Reply #7 –
Offsets cause a shift in all of the data relative to the start point.  The checksums you presented should serve as a good indicator that the raw data is different.

Mp3 encoders don't care about peaks, nor do they keep memory of previous conversions. They don't say, "hey this is the same track as before only shifted by 676 samples."

Also, the first track in the single-file image and the first track ripped with the same offset should have the same mp3 data up to the the end, provided the image doesn't also include a pregap.