IPB

Welcome Guest ( Log In | Register )

2 Pages V  < 1 2  
Reply to this topicStart new topic
Pregap not matching log file
db1989
post Jul 22 2013, 00:37
Post #26





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



I know this has been answered in a broader sense, but just for clarity:
QUOTE (LTP @ Jul 21 2013, 18:59) *
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 (db1989 @ Jul 21 2013, 15:16) *
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.

This post has been edited by db1989: Jul 22 2013, 00:37
Go to the top of the page
+Quote Post
mjb2006
post Jul 22 2013, 01:25
Post #27





Group: Members
Posts: 860
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



QUOTE (LTP @ Jul 21 2013, 02:41) *
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? crying.gif


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. smile.gif

This post has been edited by mjb2006: Jul 22 2013, 01:27
Go to the top of the page
+Quote Post
greynol
post Jul 22 2013, 06:59
Post #28





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



QUOTE (mjb2006 @ Jul 21 2013, 17:25) *
indexes past 01

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

This post has been edited by greynol: Jul 22 2013, 07:00


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
LTP
post Jul 22 2013, 12:15
Post #29





Group: Members
Posts: 23
Joined: 7-January 11
Member No.: 87155



QUOTE (mjb2006 @ Jul 22 2013, 01:25) *
QUOTE (LTP @ Jul 21 2013, 02:41) *
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? crying.gif


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. smile.gif


Thanks, but I'll live just about! biggrin.gif
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 (db1989 @ Jul 22 2013, 00:37) *
I know this has been answered in a broader sense, but just for clarity:
QUOTE (LTP @ Jul 21 2013, 18:59) *
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 (db1989 @ Jul 21 2013, 15:16) *
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 (lvqcl @ Jul 21 2013, 16:33) *
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.

This post has been edited by LTP: Jul 22 2013, 12:47
Go to the top of the page
+Quote Post
greynol
post Jul 22 2013, 12:33
Post #30





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



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.

This post has been edited by greynol: Jul 22 2013, 12:38


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
LTP
post Jul 22 2013, 12:45
Post #31





Group: Members
Posts: 23
Joined: 7-January 11
Member No.: 87155



QUOTE (greynol @ Jul 22 2013, 12:33) *
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?

This post has been edited by LTP: Jul 22 2013, 12:54
Go to the top of the page
+Quote Post
greynol
post Jul 22 2013, 13:09
Post #32





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



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.

This post has been edited by greynol: Jul 22 2013, 13:31


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
db1989
post Jul 22 2013, 14:03
Post #33





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



QUOTE (greynol @ Jul 22 2013, 12:33) *
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.
Go to the top of the page
+Quote Post
Wombat
post Jul 22 2013, 23:42
Post #34





Group: Members
Posts: 1120
Joined: 7-October 01
Member No.: 235



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
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

Go to the top of the page
+Quote Post
greynol
post Jul 23 2013, 01:05
Post #35





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



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 (Wombat @ Jul 22 2013, 15:42) *
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.

This post has been edited by greynol: Jul 23 2013, 21:09


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Goratrix
post Jul 23 2013, 08:34
Post #36





Group: Members
Posts: 131
Joined: 5-August 08
Member No.: 56722



QUOTE (LTP @ Jul 21 2013, 19:59) *
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.
Go to the top of the page
+Quote Post

2 Pages V  < 1 2
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: 26th December 2014 - 23:58