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 not matching log file (Read 13584 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Pregap not matching log file

Reply #25 –
I know this has been answered in a broader sense, but just for clarity:
Quote from: LTP on
00:01:42 and 0:00:01.42 not being the same time makes my head spin.
These are two different formats for representing the same value in time. I guess you know about centimetres and inches; this is just like that, two different formats representing the same measured quantity. As I said above:
Quote from: db1989 on
just try some conversions between min:sec:frames and h:min:sec.msec, and you might find that your confusion vanishes once you properly take on board what lvqcl said.
Which, to elaborate since I must not have been explicit enough before, means that (A) reports in the format n:n:n measure minutes, seconds, and frames (1/75th of a second), whereas (B) figures in the format n:n:n.n measure hours, minutes, and seconds with a decimal point. Colons separate quantities of different magnitude, i.e. numbers that should be multiplied by differing units (hour, minute, etc.). The period does not do this, for the values on both sides are in the same unit of seconds: serving as a decimal point, its task is to delimit the integer part (whole number) of that unit from the fractional one. These guidelines can be fairly reasonably assumed to apply in other scenarios, too, so they’re worth understanding.

Pregap not matching log file

Reply #26 –
Quote from: LTP on
Basically, XLD is saying the rip is accurate and has verified it as so, does that mean I have an exact copy of that rare live CD and to just ignore the nagging OCD discrepancy or do I need to hunt down and pay a fortune for this thing over eBay so I know I have the real thing? 


I can't resist the temptation to feed your OCD by telling you that AccurateRip calculations ignore the first and last 5 frames, so you'll never know for sure if you have an "exact copy", as far as that one-fifteenth of a second of audio on each end of the disc.

And then, aside from the audio, you have to consider that the cue sheet and log aren't telling you what the ripper didn't scan for. Just because it's not in the cue sheet doesn't mean it wasn't on the original disc. How about indexes past 01, MCN/barcode, pre-emphasis flags in the subcode, or a data track?

So you really can't expect an exact copy.

Pregap not matching log file

Reply #27 –
Quote from: mjb2006 on
indexes past 01

Is this a problem with XLD?  EAC has been able to do this with several titles that I own.

Pregap not matching log file

Reply #28 –
Quote from: mjb2006 on
Quote from: LTP on
Basically, XLD is saying the rip is accurate and has verified it as so, does that mean I have an exact copy of that rare live CD and to just ignore the nagging OCD discrepancy or do I need to hunt down and pay a fortune for this thing over eBay so I know I have the real thing? 


I can't resist the temptation to feed your OCD by telling you that AccurateRip calculations ignore the first and last 5 frames, so you'll never know for sure if you have an "exact copy", as far as that one-fifteenth of a second of audio on each end of the disc.

And then, aside from the audio, you have to consider that the cue sheet and log aren't telling you what the ripper didn't scan for. Just because it's not in the cue sheet doesn't mean it wasn't on the original disc. How about indexes past 01, MCN/barcode, pre-emphasis flags in the subcode, or a data track?

So you really can't expect an exact copy.


Thanks, but I'll live just about!
Had a similar issue a while back with a rip I did of Idlewild's last album which had a data track and thus my cue came back as inaccurate for some reason because of that, that gave me a small OCD headache as well but the end of the day the audio was good so I'll cope somehow. Eventually the nagging goes away.

Quote from: db1989 on
I know this has been answered in a broader sense, but just for clarity:
Quote from: LTP on
00:01:42 and 0:00:01.42 not being the same time makes my head spin.
These are two different formats for representing the same value in time. I guess you know about centimetres and inches; this is just like that, two different formats representing the same measured quantity. As I said above:
Quote from: db1989 on
just try some conversions between min:sec:frames and h:min:sec.msec, and you might find that your confusion vanishes once you properly take on board what lvqcl said.
Which, to elaborate since I must not have been explicit enough before, means that (A) reports in the format n:n:n measure minutes, seconds, and frames (1/75th of a second), whereas (B) figures in the format n:n:n.n measure hours, minutes, and seconds with a decimal point. Colons separate quantities of different magnitude, i.e. numbers that should be multiplied by differing units (hour, minute, etc.). The period does not do this, for the values on both sides are in the same unit of seconds: serving as a decimal point, its task is to delimit the integer part (whole number) of that unit from the fractional one. These guidelines can be fairly reasonably assumed to apply in other scenarios, too, so they’re worth understanding.


To surmise as this is all incredibly fascinating and a true learning experience for me!

0:00:02.84 = 0 hrs 00 mins 02.84 secs = 2.84 secs
00:02:63 = 00 mins 02 secs 63 frames = 2 secs 63 frames (75 frames = 1 second thus 63 frames = .84 of a second)

0:00:01.96 = 0 hrs 00 mins 01.96 = 1.96 secs
00:01:72 = 00 mins 01 secs 72 frames = 1 secs 72 frames (75 frames = 1 second thus 72 frames = .96 of a second)

Correct?
All this time I have been thinking 00:00:00 and 00:00.00 where essentially different ways of saying mins/seconds/frames so that was my big mistake right there.

Quote from: lvqcl on
00:01:42 and 00:01.42 are not the same amount of time!


In terms of the Lou Reed CD then, Track 9 (The Bed, amazing song) 00:04:68 on my rip and 0:00:04.68 on the download
0:00:04.68 = 0 hrs 00 mins 04.68 secs
00:04:68 = 00 mins 01 secs 68 frames
68 from 75 would not appear to equal .68 of a second if 63 frames = .84 earlier? I'm probably just being dumb but this has me confused a little still. Since the contents of the download CD is identical to my proper CD, just a different issue, yet mine uses 00:00:00 and the other 00:00.00 but then the pre-gap is identical, when surely by the above logic it would mean each track on one would be ever-so-slightly longer than the other. I would appreciate if someone could help shine a little light that one for me if at all possible.

Pregap not matching log file

Reply #29 –
I fear you're being misled.

I will not speak for XLD, but for EAC the log always uses X:XX:XX.XX as the format when writing pregaps, regardless of whether the last pair of digits is in frames or is in decimal.

Also, > means greater than and < means less than. 68 is not > 75; nor is 72 > 75. Besides that, the number that the digits will not exceed when they are in frames is 74, not 75.

Pregap not matching log file

Reply #30 –
Quote from: greynol on
I will not speak for XLD, but for EAC the log always uses X:XX:XX.XX as the format when writing pregaps, regardless of whether the last pair of digits is in frames or is in decimal.

Also, > means greater than and < means less than. 68 is not > 75; nor is 72 > 75. Besides that, the number that the digits will not exceed when they are in frames is 74, not 75.


Sorry, in this case I wasn't using > in it's mathematical functionality rather in a loose 'compared to' capacity, probably not the right way to do things but seemed the best visual metaphor at the time, have quickly fixed that now.

I see, XLD always rips as 00:00:00, or at least does for me, and I have no idea how to change the setting for how it displays cues any more than I know how to change whether it rips using frames or decimals, so this is where I am getting confused.
Basically you are saying it could be either/or then. Is there some way of telling from the .log whether it was ripped as one or the other or just an educated guess?

Pregap not matching log file

Reply #31 –
Again, I am only talking about EAC.  Earlier I said CUE sheets are always in frames, so this comment about the format being the same regardless of frames or decimal does not apply to them.

One other trick to determine which us being used in the EAC log:
If the log contains a table of contents, it will always be in frames. If the first track starts after 0:00.00 then you can compare the last two digits with that in the first pregap listed. If they are the same then the pregap times are in frames. If they are different then they are in decimal.

I know of no other ways to be certain which is being used if there are no pregaps listed that have the last pair of digits >74.  If the first track starts at 0:00.00 then the log may be using either frames or decimal.  Well, that isn't completely true. If the tracks were ripped with gaps left out, pre-pended to the current track or the rip was done as individual indicies then you can be able to tell which was used.

Pregap not matching log file

Reply #32 –
Quote from: greynol on
I fear you're being misled.

I will not speak for XLD, but for EAC the log always uses X:XX:XX.XX as the format when writing pregaps, regardless of whether the last pair of digits is in frames or is in decimal.
Erm, oops. Sorry if I have minunderstood, and therefore mis-explained, anything here. In my defence (to some extent!), this is a rather silly little inconsistency that can do nothing but confuse people for no good reason.

Pregap not matching log file

Reply #33 –
Somehow this thread gives the impressipon that gap handling is a gamble while it isn´t imho.

I did rip Patricia Barbers latest Smash, Concord Music. This CD has a structure with varying gaps.
2 different drives detect the gaps exactly the same as shown in the table.
I normaly don´t do any gap detection prior to ripping. I just rip to individual tracks with gaps appended.
Of course the files after ripping to individual tracks with gaps appended are 100% identical in lenght.
Differences seem to be very common on different pressings.

Did i miss something or is there some real evidence that gap handling can cause problematic different disc layouts that are more off as some milliseconds?

Code: [Select]
Plextor W5224A & Optiarc AD-7201S

Track  1
     Pre-gap length  0:00:02.00    
Track  2
     Pre-gap length  0:00:00.51
Track  3
     Pre-gap length  0:00:03.26
Track  4
     Pre-gap length  0:00:03.53
Track  5
     Pre-gap length  0:00:00.28
Track  6
     Pre-gap length  0:00:00.25
Track  7
     Pre-gap length  0:00:03.05
Track  8
     Pre-gap length  0:00:01.49
Track  9
     Pre-gap length  0:00:01.66
Track 10
     Pre-gap length  0:00:01.11
Track 11
     Pre-gap length  0:00:01.25
Track 12
     Pre-gap length  0:00:03.42

Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Pregap not matching log file

Reply #34 –
Be careful not to extrapolate two data points to the entire world.

I know of a couple discussions comparing EAC's various settings and drives both here and at digital-inn.de as well as Andre talking about potential inaccuracies in such measurements.

So yes, this is documented.

EDIT: Here, I dug this up for you...
http://www.hydrogenaudio.org/forums/index....showtopic=49266

Quote from: Wombat on
Of course the files after ripping to individual tracks with gaps appended are 100% identical in lenght.

No surprise here since pre-gaps will never affect track lengths when they are appended to the previous track.

Pregap not matching log file

Reply #35 –
Quote from: LTP on
but I do like to know why something is the way it is, and more importantly in the case of the rip, whether it is an accurate rip or some internet troll putting a dud out there.


Yes, I think most of us understand this, but you still seem to be missing the point. INDEX00 detection has NO EFFECT of the accuracy of the rip whatsoever. As long as "gaps appended to previous track" is enabled, you don't even need to detect gaps to get a perfect rip. They don't matter for anything apart from that -5, -4, -3... countdown that some CD players display.