|
Your WAV compare would say "12 missing samples" whether you had the right offset or not. All it means is that one WAV is 12 samples offset from the other. ;)
I'd say that CDFreaks is pretty reliable but not 100%. Probably the best thing for you to do would be to get AccurateRip. AccurateRip checks your drive's offset based off of a scan of one of many known CD's, and then checks it against a database to determine your drive's offset. Then, everytime you rip a CD, it will compare the checksums against a database to be sure that each track was ripped accurately. |
The problem is, I barely have any CDs that are in AccurateRip's database. I tested most of them and they all give me an error message, stating that "This CD is not in AccurateRip's database. Please insert a different Key Disc." =/
Eleo's guide says that if I'm following it exactly as it states, then I don't need AR. Which I'm doing. Quote:
|
Spoiler:
Sup Eleo? This is one of my logs from ripping. I noticed unlike your log, it doesn't have "Track quality: xx%" anywhere. Your version appears a little outdated but is there a possible solution to this that I've glanced over? Great guide, btw. |
Elixir, you used Burst mode.
Also, Blue_Kirby, AccurateRip has two functions. One is to find your drive offset. It's other function is to compare your rips to the results of other people who have ripped the CD to see if your rips match. If you're using Test/Copy when you rip your CDs, and the CRCs are identical, AND you have the right offset for your drive, AND there are no errors during the ripping process, the chances that your rip are incorrect are very, very slim. Your drive is essentially attempting to rip the same data twice and getting the exact same results each time, which is a good thing; it means that it's most likely doing it correctly. If you're not using a secure ripping method or not using Test/Copy, there's no way to really verify that your rip is accurate just by looking at the logs. That's when AccurateRip comes in; it checks your results against other people's results and tells you if your results match up or not. AccurateRip isn't always perfect for a lot of reasons, BUT it will never tell your that you ripped something correctly when you didn't. But it MIGHT imply your rip is not correct when it is. This is because a lot of CDs have multiple pressings, so the results in the AccurateRip database might be from a different pressing of the exact same album you have. A different pressing of the same CD causes a slight difference in the data. |
I am always using Test/Copy, and so far none of the CDs I've ripped (using this guide - I ripped two more CDs last night) are causing problems. Thanks for the tips.
|
Alright, I've just ripped again with Burst off.
The bitrates are identical, however, so I can assume that the songs are also? |
Bitrates don't matter if you're working with FLAC. FLAC has its own bitrate, so EAC doesn't care what bitrate setting you use when ripping CDs.
|
Okay. So is the difference between a ripped OST using Burst, and a ripped OST without Burst of any significance? I really don't want to tag and rename a 2 disc OST if it isn't necessary.
|
You'll have to ask Eleo regarding that. I've never ripped using Burst mode, and I don't know what that is.
Sorry I couldn't be of help on that though. |
Quote:
A CD ripped with Burst mode isn't always secure. I would recommend you rerip whatever you have ripped. |
No, I mean bitrates. They're identical so I just assumed that they were alike.
I guess I'll rerip them without using burst, but I really don't see any difference. |
The option's really just there because sometimes the ripping process fails to activate in one mode or the other.
|
3 Attachment(s)
Another pregap question here! Are CUE files supposed to be off in comparison to the listing in EAC and the LOG? Take a look below to see what I am talking about, though for some reason the CUE listing for the gap isn't the same as is listed in the LOG. This is an issue on all my rips! Call me confused... :tpg:
|
Well every audio CD has a gap of two seconds (I think; there may be some exceptions, I don't know); it's normal for the CUEsheet to exclude the first two seconds from its pregap flag because it's assumed they exist.
Then you have to take into account that EAC is measuring in seconds when time on a CD is generally measured in frames. It is my understanding that frames are the "correct" unit of measurement for time on a CD. I believe EAC natively displays time in hundredths of a second (you can change this option in Options -> General tab), which is more precise than necessary, because there are only 75 frames in a second on a CD. So in your log you have 2.44 seconds. In your cue, those 2 seconds are ignored, leaving you with 44 hundredths of a second; which is equal to 33 frames. (100/75 = 44/33). Similarly, 64 hundredths of a second equal to 48 frames, and so on. You can do the conversions for yourself. Bottom line, just ignore it :) Double Post: Thinking about it, your question would make a good addition to the FAQ. |
How do i tell if a rip is accurate or not without having the original myself? I ask because someone ripped the DMC3 OST in flac and i want to up that to the tracker but sabbey asked if it was accurate.
|
You won't be able to compare it unless you have some documentation on the original to compare it to, sorry.
The tracker now has "Non-proper" torrent catagories for just this purpose. |
Assuming it has a CUE and LOG, that should be fine as in regards to if it's proper, right?
BTW, thanks Eleo for the pregap info. Was scratching my head over that one! ;) |
Yes there is a cue file with the rip BUT the filenames in the cue file are in anothe language which would make things more complicated since I had to retag all 104 tracks.
|
Okey, so I want to rip this CD that I have. The format is .oma or .omg, meaning that it's some sony stuff. EAC can't handle it, gives me sync errors everytime I try. So I read that dbpowerAMP can rip it.
My question being this: Are there any differences between EAC and dbpowerAMP? Will it still be lossless when I rip it? Will it still be the same quality as any standard EAC rip? |
.oma and .omg are containers for Sony's ATRAC format, which is lossy (and lousy, at that). You got shafted.
|
But it's an original CD, not some junk I downloaded from the net. And it's the official release of that CD, not a bootleg. How can an original CD be lossy? I'm confused.
|
It's probably just their crappy idea of copy-protection. Seems most now give lossy versions of the music on such protected CDs when used on a PC rather than a standard CD player. Not that it will always work either though... :rolleyes:
If you want CD quality I'd recommend either finding another version of the CD if it's mainstream (Since there's a slim chance not all versions of the CD around the globe are protected) or a way to burn it and send Sony a message, by demanding a full refund either way. Which CD is it BTW, maybe there's another issue at work? |
Most CDs I've come across nowadays in the stores have two prints - one of them being a double-sided disc (one side with the music, the other side with DVD content), and another print with the music only. The print with the DVD content usually comes in these weird cases. I tried to rip one of those a long time ago but it failed since it was copy-protected. As far as I remember the CD prints with the music only didn't have copy-protection.
I don't know how Canada prints their music compared to the US, though. |
Quote:
Exact Audio Copy will handle it just fine if your CD-ROM drive is any good. |
Is it still lossy? Cause if it is there is no point in trying to rip it, because I want it lossless.
I have a NEC DVD RW 3550A. I tried ripping it, but it gave me a bunch of sync errors. I tried it with the standard EAC lossless ripping setup (Eleo's guide). Maybe I need to change some settings? And here is a link to the CD. http://www.cdon.com/main.phtml?navroot=904&session=1 Duran Duran - Astronaut (CD+DVD) |
| All times are GMT -5. The time now is 01:09 AM. |
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2025, vBulletin Solutions, Inc.