Gamingforce Interactive Forums
85202 35210

Go Back   Exploding Garrmondo Weiner Interactive Swiss Army Penis > Garrmondo Music and Trading > Behind the Music


Welcome to the Exploding Garrmondo Weiner Interactive Swiss Army Penis.
GFF is a community of gaming and music enthusiasts. We have a team of dedicated moderators, constant member-organized activities, and plenty of custom features, including our unique journal system. If this is your first visit, be sure to check out the FAQ or our GFWiki. You will have to register before you can post. Membership is completely free (and gets rid of the pesky advertisement unit underneath this message).

Question about pregaps
Thread Tools
The Raven

Member 2985

Level 17.51

Mar 2006

Reply With Quote
Old Jun 26, 2009, 10:00 AM Local time: Jun 26, 2009, 08:00 AM #1 of 1
Question about pregaps

First of all, when I detect pregaps in EAC, that shit's different every single time. For example, I was ripping Am Universum yesterday. I've come up with only one song having a pregap (1.9 seconds on Veil of Sin or something), or I've had 6 of the 10 songs have pregaps (and Veil of Sin was now 1.7 or something).

I've done a rip with the 1.9 pregap and a rip with the 1.7 pregap. When I check them against AccurateRip using CUE Tools, both are said to be 100% accurate with the rips in the database.

Here's what I don't understand: I can take the CUE Sheet of the 1.7 pregap rip and paste it into the directory of the 1.9 rip. I can then open that CUE Sheet and re-rip it using those pregap settings. So the one done in 1.9 pregap settings are now done in 1.7 pregap settings. REMEMBER: AccurateRip called these two different rips EQUAL.

Now let's take the Veil of Sin ripped with the 1.7 from the CD and the one I did myself from the 1.9. I take them both (but keep in mind they both have 1.7 second pregaps) and open them up in a hex compare program (they are WAV files just so you know).

There is literally not one single difference in either of the files. They are identical. The 1.7 pregap rip I did from the CD and the one I altered from the 1.9 pregap rip are identical.

So I check the rip I did manually with the 1.7 pregaps settings against AccurateRip. Every single track that had a pregap said that there were NO MATCHES in the database.

My fucking question: WHY???? I checked the files. They were bit-for-bit identical. Numerically equal. Why, when it comes from a CD, does AccurateRip accept it, but when I do it myself AND IT COMES OUT EXACTLY THE SAME mind you, AccurateRip does not accept it?

In fact, why can AccurateRip even accept two different pregap setting rips in the first place?

EDIT: In case this is a little hard to understand, Veil of Sin has over two seconds of silence at the beginning of the track. EAC has called 1.7 seconds of this and 1.9 seconds of this a "pregap", but this pregap is still part of the same song. What I'm doing (to my knowledge) is not moving the silence around, but simply calling only a certain part of it a "pregap". If calling certain data a pregap was moving it around, then AccurateRip wouldn't have let the first 1.7 rip I did from the CD fly, right? The exact same amount of data is still in the exact same place on every single rip I'm doing. Which is why I can't understand why AccurateRip would tell me two essentially identical rips are not identical - they both of a pregap of 1.7 seconds whether EAC said they did or not.

Jam it back in, in the dark.

Thread Tools

Exploding Garrmondo Weiner Interactive Swiss Army Penis > Garrmondo Music and Trading > Behind the Music > Question about pregaps

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
How do you answer the job interview question of... Divest General Discussion 25 Dec 19, 2007 06:26 PM
The impossible quiz! S_K Pang's Violence Basement 16 Sep 12, 2007 11:39 AM
Kid Suspended for Refusing to Answer Exam Question Koneko General Discussion 69 Nov 13, 2006 02:08 PM

All times are GMT -5. The time now is 04:04 PM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2019, vBulletin Solutions, Inc.