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: PREGAP cut out from cuesheets (Read 1325 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

PREGAP cut out from cuesheets

Good day everybody.

I think I found a quite nasty glitch in the way foobar handles cuesheets.

The problem emerged while ripping my CD "Tango: Zero Hour" by Astor Piazzolla and I'll make reference to that rip from now on.

Please let me explain how I got to that conclusion and sorry if this will be quite... verbose:

I rip using EAC 1.0b3 single file + cuesheet using the "Copy Image & Create CUE Sheet" action.
My drive is a PlextWriter Premium configured to use AccurateRip, with +30 read sample offset.
In EAC Extraction settings I have set "Fill up missing offset samples with silence", but I think this is not relevant as the drive is declared to be able to "Over-read into Lead-In and Lead-Out"


This is the original cuesheet of my rip:
Code: [Select]
REM GENRE Tango
REM DATE 1986
REM DISCID 4B0AD507
REM COMMENT "ExactAudioCopy v1.0b3"
CATALOG 0075597946925
PERFORMER "Astor Piazzolla"
TITLE "Tango: Zero Hour"
FILE "Astor Piazzolla - Tango- Zero Hour.wav" WAVE
  TRACK 01 AUDIO
    TITLE "Tanguedia III"
    PERFORMER "Astor Piazzolla"
    ISRC USNO18746901
    INDEX 00 00:00:00
    INDEX 01 00:00:32
  TRACK 02 AUDIO
    TITLE "Milonga del Angel"
    PERFORMER "Astor Piazzolla"
    ISRC USNO18746902
    INDEX 00 04:39:42
    INDEX 01 04:39:45
  TRACK 03 AUDIO
    TITLE "Concierto Para Quinteto"
    PERFORMER "Astor Piazzolla"
    ISRC USNO18746903
    INDEX 00 11:11:00
    INDEX 01 11:11:02
  TRACK 04 AUDIO
    TITLE "Milonga Loca"
    PERFORMER "Astor Piazzolla"
    ISRC USNO18746904
    INDEX 00 20:17:70
    INDEX 01 20:17:72
  TRACK 05 AUDIO
    TITLE "Michelangelo '70"
    PERFORMER "Astor Piazzolla"
    ISRC USNO18746905
    INDEX 00 23:27:22
    INDEX 01 23:27:32
  TRACK 06 AUDIO
    TITLE "Contrabajissimo"
    PERFORMER "Astor Piazzolla"
    ISRC USNO18746906
    INDEX 00 26:18:37
    INDEX 01 26:19:22
  TRACK 07 AUDIO
    TITLE "Mumuki"
    PERFORMER "Astor Piazzolla"
    ISRC USNO18746907
    INDEX 00 36:38:65
    INDEX 01 36:38:67
And this is the associated log:
Code: [Select]
Exact Audio Copy V1.0 beta 3 from 29. August 2011

EAC extraction logfile from 14. March 2012, 23:48

Astor Piazzolla / Tango: Zero Hour

Used drive  : PLEXTOR CD-R   PREMIUM   Adapter: 4  ID: 0

Read mode               : Secure
Utilize accurate stream : Yes
Defeat audio cache      : No
Make use of C2 pointers : Yes

Read offset correction                      : 30
Overread into Lead-In and Lead-Out          : Yes
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 : Internal WAV Routines
Sample format      : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  |  0:00.32 |  4:39.13 |        32    |    20969   
        2  |  4:39.45 |  6:31.32 |     20970    |    50326   
        3  | 11:11.02 |  9:06.70 |     50327    |    91346   
        4  | 20:17.72 |  3:09.35 |     91347    |   105556   
        5  | 23:27.32 |  2:51.65 |    105557    |   118446   
        6  | 26:19.22 | 10:19.45 |    118447    |   164916   
        7  | 36:38.67 |  9:34.08 |    164917    |   207974   


Range status and errors

Selected range

     Filename D:\smz\Desktop\Astor Piazzolla - Tango- Zero Hour.wav

     Peak level 89.1 %
     Extraction speed 25.3 X
     Range quality 99.9 %
     Copy CRC 9B957D0E
     Copy OK

No errors occurred

 
AccurateRip summary
 
Track  1  accurately ripped (confidence 7)  [CA7A6D98]  (AR v2)
Track  2  accurately ripped (confidence 7)  [55139BC6]  (AR v2)
Track  3  accurately ripped (confidence 7)  [52793E2C]  (AR v2)
Track  4  accurately ripped (confidence 7)  [A751D6CD]  (AR v2)
Track  5  accurately ripped (confidence 7)  [7C750F3A]  (AR v2)
Track  6  accurately ripped (confidence 7)  [9B2DC251]  (AR v2)
Track  7  accurately ripped (confidence 7)  [49A3A7CA]  (AR v2)
 
All tracks accurately ripped

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: 5GaHVKQNvoMv10gS7nVA5VH7kQY-] found, Submit result: database access error: The operation has timed out
[1f78babc] (42/42) Accurately ripped


==== Log checksum 29292FAB4330372887C0317E391CCB6933402800C2A4E4328BA375EECDC3A567 ====

As you can see from the log the disc was correctly ripped as per AccurateRip v2 results.

Just to be sure I verified the rip using CueTools too, and this are the results:
Code: [Select]
[CUETools log; Date: 2012-03-15 00:35:09; Version: 2.1.2a]
Pregap length 00:00:32.
[CTDB TOCID: 5GaHVKQNvoMv10gS7nVA5VH7kQY-] found.
        [ CTDBID ] Status
        [1f78babc] (42/42) Accurately ripped
[AccurateRip ID: 000b9714-00466b73-4b0ad507] found.
Track   [ CRC    ] Status
 01     [497b6468] (46/53) Accurately ripped
 02     [7966255d] (46/53) Accurately ripped
 03     [db6813c2] (46/53) Accurately ripped
 04     [8423958a] (44/51) Accurately ripped
 05     [3dfb6bcf] (46/53) Accurately ripped
 06     [1c9aeffa] (45/52) Accurately ripped
 07     [5f14083f] (44/51) Accurately ripped
AccurateRip v2:
 01     [ca7a6d98] (07/53) Accurately ripped
 02     [55139bc6] (07/53) Accurately ripped
 03     [52793e2c] (07/53) Accurately ripped
 04     [a751d6cd] (07/51) Accurately ripped
 05     [7c750f3a] (07/53) Accurately ripped
 06     [9b2dc251] (07/52) Accurately ripped
 07     [49a3a7ca] (07/51) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --   89.1 [9B957D0E] [9A378A75]   CRC32   
 01   89.1 [8475524C] [535980E0]           
 02   62.4 [7F829A88] [2B278808]           
 03   80.8 [54A5612D] [AA57C4D2]           
 04   78.2 [AF2F60E5] [92DF0692]           
 05   70.8 [7EF58576] [B0009F28]           
 06   75.7 [5E601268] [86E62CD6]           
 07   51.6 [0F60845C] [CE854DB8]
Then I loaded the cuesheet in foobar2000 (v1.1.11), selected all the tracks and proceeded to create a WavPack encoding with embedded cuesheet using the following settings:
Code: [Select]
Output format: WavPack, High compression
Output type: generate multi-track image files.
Processing: none
This will probably reveal the fact that I may be suffering of OC disorder, but I must confess that I submited to CueTools also the generated .wv file, and this is the resulting log:
Code: [Select]
[CUETools log; Date: 2012-03-15 00:42:04; Version: 2.1.2a]
CDDBId mismatch: 4B0AD507 vs 490AD407
[CTDB TOCID: 5GaHVKQNvoMv10gS7nVA5VH7kQY-] found.
        [ CTDBID ] Status
        [1f78babc] (42/42) Has pregap length 00:00:32
[AccurateRip ID: 000b9614-004666f4-490ad407] disk not present in database.

Track Peak [ CRC32  ] [W/O NULL] 
 --   89.1 [6E6492A8] [9A378A75]           
 01   89.1 [8475524C] [535980E0]           
 02   62.4 [7F829A88] [2B278808]           
 03   80.8 [54A5612D] [AA57C4D2]           
 04   78.2 [AF2F60E5] [92DF0692]           
 05   70.8 [7EF58576] [B0009F28]           
 06   75.7 [5E601268] [86E62CD6]           
 07   51.6 [0F60845C] [CE854DB8]
   
WOOOOOOOOPS.... Huston, we have a problem! (and yes, sometimes to be OC pays back, apparently)

I tried verifying the .wv from within foobar2k and here too I got bad results
Code: [Select]
No such disc found in the AccurateRip database.
Please make sure you have selected a complete disc rip with correct track order.
If the disc contains hidden tracks, you can only verify it through a matching cuesheet with hidden track information intact.
I decoded the .wv back to .wav (both from within fb2k and using wvunpack, same reults) and compared to the original file using EAC's "Compare WAVs" tool:
Code: [Select]
    
EAC WAV Compare

WAV file:        Original.wav                        WAV file:        DecodedFromWavPack.wav

Error type            Position                        Error type            Position
different samples    00:00:00:168 - 0:46:12.573        different samples    00:00:00:168 - 0:46:12.573
0:00:00.426 longer
SGRUNT!! 

Doubts about WavPack were forming in my head, so I re-encoded the original, this time using the command line, decoded back always from the command line and then compared to the original: bit perfect. Then the problem must be with foobar2000...

The mentioning of "hidden tracks" in the fb2k AR test and remembering the first track had an "INDEX 01 00:00:32" made me suspicious.

Time to do some basic math: 32 CD frames (the PREGAP) = 1/75*32 seconds = 0.426 (6 periodic for the OCs) seconds. BINGO! Exactly what was missing from the decoded WavPack

The conclusion I draw is that foobar2000 has decided to cut the first 32 frames (the PREGAP) of the first track.
This is confirmed by the fact that when I load the original cuesheet within foobar2000 in the "Properties" of the first track I see:
Code: [Select]
<PREGAP> : 00:00:32
<REFERENCED_FILE> : Astor Piazzolla - Tango- Zero Hour.wav
<REFERENCED_OFFSET> : 00:00:32
So  apparently fb2k cuts the PREGAP data from the original file and substitute it with a PREGAP cuesheet directive.

This is fair enough (marginally, from an OC point of view) if the PREGAP contains digital silence, but I think the opposite behaviour should be applied when decoding (and hence, playing, converting, or checking AR).

But there is worse than that, I'm afraid:
I substitued the digital silence in the PREGAP of the original file with a 1KHz tone and repeated the whole process.
Unhapply I have to report that my 1KHz tone was gone into the bit bucket too... 

I don't know if this is old news, but that also means that FB2K is unable to preserve hidden tracks in the PREGAP.

As I said if these are old news I missed them, and if this is how it is intended to be, sorry.
Personally, anyway, I think a program as good as FB2K should behave in a more educated lossless manner. 

Regards.

Sergio

Edit: Ooooops... should I had posted this in the "Support - (fb2k)" forum? Moderators, please feel free to move, in case.
Sergio
M-Audio Delta AP + Revox B150 + (JBL 4301B | Sennheiser Amperior | Sennheiser HD598)

PREGAP cut out from cuesheets

Reply #1 –
This is by design. In any player, including real CD players, when you start playing track 01 of a CD, playback starts at track 01 index 01, skipping index 00 (that track's pregap). This is also the behavior you would expect when selecting and converting individual tracks...the track boundaries are always index-01 to index-01, exclusive. When using a cue sheet to populate the playlist with tracks, foobar2000 simply follows this trend. You run into the same problem when using rippers to put each track in its own file; there's always the question of what to do with track 01 pregap, when it exists.
 

PREGAP cut out from cuesheets

Reply #2 –
mjb, thankyou for answering.

I started to suspect something in the lines of what you explained, I can understand the rationale behind it and I realize this is mostly a matter of personal opinion.

The fact remains, anyway, that this behavior breaks the use of AccurateRip to check that kind of single_file_with_embedded_cuesheet rips.

I made further testing and manually encoded the original file and then manually embedded the original cuesheet using Mp3tag.

The result is that this file is perfectly usable within FB2K and it checks correctly against AccurateRip. When decoded it gives me back a bit perfect copy of the original rip. This is the behaviour I like and I'll use this method from now on (unless somebody points me to undesired side effects of which I have not think).

Now, I understand that I'm going a bit OT as this becomes a "feature request", but what I'd really like to see in the future is:

1) An alternative way to encode from within FB2K giving the results I like, maybe just an "Embed cuesheet" command or an "Ignore  (don't mess with) PREGAP" option.
2) Handling of sub-indexs in FB2K's Toolbar ("Next Sub-Index", "Prev Sub-Index", "Goto Sub-Index...")

If the latter seems to be an useless option (and I admit it will be rarely used), just give a look at this cuesheet, from a rip of J.S. Bach's Goldberg Variations performed by Glenn Gould (1981):
Code: [Select]
REM GENRE Classical
REM DISCID 020C0601
REM COMMENT "ExactAudioCopy v0.95b3"
PERFORMER "Johann Sebastian Bach"
TITLE "Goldberg Variations, BWV 988 (Glenn Gould, 1981)"
FILE "Goldberg Variations, BWV 988 (Glenn Gould, 1981).wav" WAVE
  TRACK 01 AUDIO
    TITLE "Aria & 30 Variations"
    PERFORMER "Johann Sebastian Bach"
    FLAGS PRE
    INDEX 01 00:00:00
    INDEX 02 03:10:22
    INDEX 03 04:20:50
    INDEX 04 05:10:02
    INDEX 05 06:40:55
    INDEX 06 07:31:15
    INDEX 07 08:08:20
    INDEX 08 08:48:35
    INDEX 09 10:04:60
    INDEX 10 10:58:37
    INDEX 11 11:57:57
    INDEX 12 13:02:07
    INDEX 13 13:55:60
    INDEX 14 15:33:10
    INDEX 15 18:12:15
    INDEX 16 19:15:50
    INDEX 17 24:17:50
    INDEX 18 25:57:22
    INDEX 19 26:51:30
    INDEX 20 27:54:45
    INDEX 21 28:57:45
    INDEX 22 29:47:52
    INDEX 23 32:00:35
    INDEX 24 33:03:65
    INDEX 25 34:01:40
    INDEX 26 35:44:37
    INDEX 27 41:48:72
    INDEX 28 42:40:62
    INDEX 29 44:02:10
    INDEX 30 45:05:42
    INDEX 31 46:07:37
    INDEX 32 47:37:27
I also have many opera CDs where sub-indexes are used to point to a particular aria...

Thanks again!

Cheers!

Sergio

Edit: Fixed a minor typo (Glenn Gould name)
Sergio
M-Audio Delta AP + Revox B150 + (JBL 4301B | Sennheiser Amperior | Sennheiser HD598)