IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
CDs with different offsets encode to MP3 differently?
Boiled Beans
post Jun 10 2013, 15:26
Post #1





Group: Members
Posts: 173
Joined: 8-March 08
Member No.: 51870



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

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

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

[AccurateRip ID: 0017e86b-00e403df-c210920d] found.
Track [ CRC | V2 ] Status DIGIPACK PRESSING
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: JEWEL CASE PRESSING
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.

Go to the top of the page
+Quote Post
greynol
post Jun 10 2013, 15:30
Post #2





Group: Super Moderator
Posts: 10338
Joined: 1-April 04
From: San Francisco
Member No.: 13167



Yes, this is perfectly normal.

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


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Boiled Beans
post Jun 10 2013, 16:01
Post #3





Group: Members
Posts: 173
Joined: 8-March 08
Member No.: 51870



QUOTE (greynol @ Jun 10 2013, 22:30) *
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?
Go to the top of the page
+Quote Post
greynol
post Jun 10 2013, 16:04
Post #4





Group: Super Moderator
Posts: 10338
Joined: 1-April 04
From: San Francisco
Member No.: 13167



No. All data is shifted by the offset so all frames with non-null data as split by the encoder will be different.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
pdq
post Jun 10 2013, 16:09
Post #5





Group: Members
Posts: 3450
Joined: 1-September 05
From: SE Pennsylvania
Member No.: 24233



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.
Go to the top of the page
+Quote Post
Boiled Beans
post Jun 10 2013, 16:10
Post #6





Group: Members
Posts: 173
Joined: 8-March 08
Member No.: 51870



QUOTE (greynol @ Jun 10 2013, 23:04) *
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.
Go to the top of the page
+Quote Post
Boiled Beans
post Jun 10 2013, 16:14
Post #7





Group: Members
Posts: 173
Joined: 8-March 08
Member No.: 51870



QUOTE (pdq @ Jun 10 2013, 23:09) *
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!
Go to the top of the page
+Quote Post
greynol
post Jun 10 2013, 16:20
Post #8





Group: Super Moderator
Posts: 10338
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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.

This post has been edited by greynol: Jun 10 2013, 16:35


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 18th December 2014 - 19:39