kwfine
Oct 31 2007, 07:38
Hi!
while I see that EAC is still the prevailing audio grabber for CDs, I found that Foobar bears the ability to grab music CD tracks to WAV files without the need of extra plugin.
It seems only a few users would consider using Foobar to grab music from audio CDs
Does EAC have any advantages over Foobar as an audio grabber?
LaserSokrates
Oct 31 2007, 08:00
I think it's just everybody's personal preference. None of them is better or worse.
odyssey
Oct 31 2007, 08:16
I tried the fb2k ripper, but I'm not convinced about it. Sure it's secure, but VERY insecure if your drive caches, which my experience is quite a few. Edit: Fud (?) - Try yourself...
IMHO it needs a test/copy function, or better yet: The same ripping methods as dBpoweramp's Ultra Secure mode.
William
Oct 31 2007, 08:41
I have tested EAC vs foobar2000 with several CDs. The CD images ripped by both programs are identical. So I think foobar2000 is actually not bad at ripping CDs. Of course those CDs are new, so secure mode features are not that useful as with older CDs.
However with EAC you get a "safe" feeling as you can see the CRC of the ripped CD, or use the "test and copy" feature. Also EAC has pre-gap detection and testing. These are the reasons that I use EAC instead.
Frank Bicking
Oct 31 2007, 09:22
QUOTE(odyssey @ Oct 31 2007, 15:16)

I tried the fb2k ripper, but I'm not convinced about it. Sure it's secure, but VERY insecure if your drive caches, which my experience is quite a lot.
Would you please stop spreading FUD about the cache handling?
It has been explained to you how and why it works multiple times, in both
the forum and our IRC channel.
Edit:
QUOTE
IMHO it needs a test/copy function
It already performs test and copy, as you have also been told before.
odyssey
Oct 31 2007, 11:03
QUOTE(Frank Bicking @ Oct 31 2007, 17:22)

Would you please stop spreading FUD about the cache handling?
I'm only telling what I've found out myself. I have been ripping some serious scratched CD's, and for that purpose I tried to give fb2k a chance to prove it's worths as a CD ripper. The console shows a great deal of information, compared to other rippers, which is great! However when I successfully ripped the same track TWICE and compared the two binary files - THEY WERE DIFFERENT. Fud or not, people can try this themselves. I tried this with a shitty NEC drive.
greynol
Oct 31 2007, 11:41
Neither foobar2000 nor EAC have any immunity against consistent errors, but EAC has AccurateRip support and as such has an advantage that is considerable. For drives that provide reliable C2 pointers which either don't cache or accept FUA, EAC again has an advantage.
With drives that provide C2 pointers (regardless of reliability), neither of these programs can compete with dBpowerAMP.
How exactly does Foobar2000 handle drives that cache (including during re-reads in the event of a mismatch)???
Knowing this, I may be able to make a case demonstrating even greater superiority with dBpowerAMP.
Correct me if I am wrong, foobar:
Reads in 'blocks' of 4MB, that is about 1700 sectors from the cd. Works sequentially like EAC (read block, re-read block).
If there is a miss-match on the re-read it will try the same block until the two get the same match. Upto 128 times. In paranoid mode it requires 4 matches.
My thoughts on this method:
Reading such large blocks on badly damaged CDs (assuming the blocks are not stored and smartly part compared) lessens the chance of recovering the cd, all you need is 100 sectors in that block to be right on the edge of recoverability (this happens, I have seen a drive return bad results 4000 times in a row, the 4001 try gave the right result), the chance of all 100 giving the right result at a given time is lower than reading those 100 sectors, 1 sector at a time.
There is a high chance that after 128 retries (if only 1 or 2 sectors were bad), that a consistant error is reproduced, after all if 1 sector is giving semi random results, 128 is a high number that 2 random results are going to match.
Now obviously I am not impartial, please Greynol verify these thoughts.
sst-daniel
Nov 2 2007, 15:36
As far as I experienced, foobar canīt read CD-text yet. (I would be extremely happy if Iīm wrong here) And EAC does.
For normal use foobar seems to be a little bit faster and in critical cases I prefer Samplitude for ripping...
greynol
Nov 2 2007, 16:30
QUOTE(spoon @ Oct 31 2007, 13:51)

Now obviously I am not impartial, please Greynol verify these thoughts.
QUOTE(spoon @ Oct 31 2007, 13:51)

Reads in 'blocks' of 4MB, that is about 1700 sectors from the cd. Works sequentially like EAC (read block, re-read block).
If there is a miss-match on the re-read it will try the same block until the two get the same match. Upto 128 times. In paranoid mode it requires 4 matches.
This is consistent with a
post in the discussion linked in the thread cited earlier by Frank Bicking except that Peter used the term
sector instead of block when talking about re-reads. I'm not sure if this was an unfortunate choice of wording or whether it's a vague allusion to what's really going on. For example, EAC compares 2MB blocks and when it finds a discrepancy it reads 27 frames beginning with the frame where the discrepancy occurred for each re-read. If cache flushing is enabled, 2MB is read between each re-read. If foobar really re-reads an entire 4MB block in order to "fix" an error that only exists in one frame, IMO, this is truly unfortunate.
QUOTE(spoon @ Oct 31 2007, 13:51)

Reading such large blocks on badly damaged CDs (assuming the blocks are not stored and smartly part compared) lessens the chance of recovering the cd, all you need is 100 sectors in that block to be right on the edge of recoverability (this happens, I have seen a drive return bad results 4000 times in a row, the 4001 try gave the right result), the chance of all 100 giving the right result at a given time is lower than reading those 100 sectors, 1 sector at a time.
This makes perfect sense to me, but there's still the troubling outcome of consistent errors as you mentioned...
QUOTE(spoon @ Oct 31 2007, 13:51)

There is a high chance that after 128 retries (if only 1 or 2 sectors were bad), that a consistant error is reproduced, after all if 1 sector is giving semi random results, 128 is a high number that 2 random results are going to match.
As has been mentioned here and at other forums already, many errors
appear to give random results, but when the error only affects a small number of samples it's quite easy to get wrong results that are consistent. Spath expressed an interest in writing an article about the subject a while back, but I haven't heard about it since.
greynol
Nov 2 2007, 16:56
In defense of foobar2000 over EAC when it comes to drives that cache, if foobar2000 only requests 2MB for each 1MB of secure data, it's certainly more efficient than EAC's requesting of 3MB for each 1MB of secure data.
Martin H. recently posted a request at Digital-Inn that EAC do away with block synchronization with drives configured as having the Accurate Stream feature. This would do away with the need for the extra flushing that's involved.
odyssey
Nov 2 2007, 17:51
QUOTE(Frank Bicking @ Oct 31 2007, 17:22)

QUOTE(odyssey @ Oct 31 2007, 15:16)

I tried the fb2k ripper, but I'm not convinced about it. Sure it's secure, but VERY insecure if your drive caches, which my experience is quite a lot.
Would you please stop spreading FUD about the cache handling?
It has been explained to you how and why it works multiple times, in both
the forum and our IRC channel.
Edit:
QUOTE
IMHO it needs a test/copy function
It already performs test and copy, as you have also been told before.
Highlights from the IRC discussion:
QUOTE
<odys> Neptune: nevertheless, my terrible nec drive seems not to care, and i've ripped several tracks in no time with it in secure mode, that all ended up different
QUOTE
<odys> bottom line: with that drive i'm completely unable to get secure rips in foobar
QUOTE
<GenjuroXL> you can't get any secure rips with an NEC drive
I did not find any reference to an explanation why foobar fails to produce two exact rips from a scratched CD using the NEC drive.
thekief
Nov 2 2007, 18:23
I really wish a logging function was added - similar to EAC's output....
greynol
Nov 2 2007, 18:33
QUOTE(odyssey @ Nov 2 2007, 16:51)

I did not find any reference to an explanation why foobar fails to produce two exact rips from a scratched CD using the NEC drive.
I can assure you that caching has nothing to do with it.
GenjuroXL
Nov 3 2007, 02:51
What I wanted to say: NEC drives suck for audio extraction. It's not a foobar problem, it's a general problem (had enough experience with bad NEC audio extraction...)
greynol
Nov 3 2007, 13:04
Depending on the disc and the way your drive interacts with the software you may get different results between different programs. In accordance with what spoon has said earlier, as you narrow the focus of what you re-read, the ability to get consistent data increases; but consistent data most certainly does not mean error-free data.
It may even be worse than this. From what I've read, foobar2000 may only be searching for repeatable data rather than consistent data. Who's to say that out of 128 attempts there aren't more than one set that can re-occur? I can't be exactly sure but it seems that foobar2000 may simply move on once it finds the first set of data that satisfies its criteria. This would be much less picky than the way EAC works, which itself is far from perfect.
Also, for NEC 3XXX drives and earlier, allowing EAC to rely on C2 pointers is a terrible idea.
QUOTE(odyssey @ Oct 31 2007, 16:16)

IMHO it needs a test/copy function, or better yet: The same ripping methods as dBpoweramp's Ultra Secure mode.
Do a bitcompare between the cd tracks and the ripped tracks, it will show any differences (of course it only works if you ripped in lossless format).
But as it was said before, it already does test & copy so this may be redundant.
indybrett
Nov 3 2007, 16:23
Can dbPoweramp rip image + cue files? If so, I may want to try it again.
greynol
Nov 7 2007, 10:11
QUOTE(indybrett @ Nov 3 2007, 15:23)

Can dbPoweramp rip image + cue files? If so, I may want to try it again.
Though I haven't tried it, the new beta of R13 can.
Cue sheets are not in yet. Cue + image ripping will be done slightly differently.
Phil Friel
Nov 12 2007, 00:48
Spoon & Greynol:
I'm new at this high-end audiophile stuff, so please bear with me as I ramble a bit.
I've recently decided to archive my large CD collection onto my two new 500GB hard drives. Up until not so long ago, I'd just bung a CD in my computer and let MediaMonkey rip the CD to MP3. But I've become dissatisfied with the quality of MP3, OGG or any other lossy format, so I've decided to start over from scratch and rip everything to lossless. The absolute top priority now is obtaining the highest possible quality rips of each individual track.
I'm really only starting out on this, but I really want to do it right this time around. So far, I've only ripped several hundred songs to WAV with EAC. It would be a real pain to have to start over again at some point in the future, after having ripped thousands of songs. It would be a lot easier to get things right at this early stage.
I use several different programs to playback music - MediaMonkey for general music management at home, and two different DJing programs at work - Traktor 3 and SAM Party DJ. I also have a DAP - a Cowon iAudio X5 (the 60GB version). I have my own little system for ripping music, which is probably a bit complex and convoluted, but it works for me:
I rip to WAV and keep the original non-normalized WAVs as backups on a separate hard drive.
I make copies of these WAVs, which I put through Wavegain to even everything out at -89db.
From these copies, I convert to FLAC for use in MediaMonkey, Traktor 3, and on my Cowon iAudio X5, and to WMA Lossless for use in SAM Party DJ (doesn't support FLAC - yet - when it does, I can get rid of the WMAs). I then delete all the WAV copies to conserve space. The FLAC/WMA versions can be tagged, and take up less space. I don't need much in the line of tagging (although it's nice to have) - I'm generally only interested in Artist Name, Track Name, original Album Name, and Year.
In the vast majority of cases I rip individual tracks rather than whole albums at once. Most albums (with the exception of Best of/Greatest Hits) usually only contain several songs that I'd want to rip. And, as a DJ, I tend to organize my music more on an individual song basis rather than on an album basis. Would I be right in assuming that this method of ripping makes AccurateRip useless for my needs?
Finally, to bring this rambling post right back on topic (lest I be accused of hijacking the thread), the final BIG QUESTION: I've decided, for ripping purposes, to go for the best software available. I've narrowed it down to a choice between Foobar, EAC and dbPowerAmp. Given that my top priority is obtaining the highest quality audio extraction on an individual track basis (so I'd want extremely secure ripping of individual tracks), again followed by the ability to handle copy-protected CDs, and looking at how I do stuff as per the post above, which of these three programs would you recommend I use?
From what I've read in this thread so far, I'd reckon it comes down to a head-to-head between EAC and dbPowerAmp, as they seem to edge Foobar in some areas. What do you guys think?
Phil
greynol
Nov 12 2007, 02:10
QUOTE(Phil Friel @ Nov 11 2007, 22:48)

In the vast majority of cases I rip individual tracks rather than whole albums at once. [...] Would I be right in assuming that this method of ripping makes AccurateRip useless for my needs?
No. AccurateRip works on a track-by-track basis. Ripping an entire album is not necessary.
QUOTE(Phil Friel @ Nov 11 2007, 22:48)

Given that my top priority is obtaining the highest quality audio extraction on an individual track basis (so I'd want extremely secure ripping of individual tracks), again followed by the ability to handle copy-protected CDs, and looking at how I do stuff as per the post above, which of these three programs would you recommend I use?
The ability to successfully rip a copy-protected lies in the drive, not the software.
QUOTE(Phil Friel @ Nov 11 2007, 22:48)

From what I've read in this thread so far, I'd reckon it comes down to a head-to-head between EAC and dbPowerAmp, as they seem to edge Foobar in some areas. What do you guys think?
I'm guessing you're interested in other people's opinions besides Spoon and myself since I've already given my reasons as to why not to use foobar and Spoon is the author of dBpowerAMP. I think he is justified in believing he has created the best program of the three and for drives that provide C2 pointers I have to agree with him.
odyssey
Nov 12 2007, 02:27
QUOTE(Phil Friel @ Nov 12 2007, 07:48)

I make copies of these WAVs, which I put through Wavegain to even everything out at -89db.
I wouldn't do that. Wavegain is a lossy process. You reduce the SNR ratio (given you want the highest quality, that seems to defeat the purpose)
QUOTE(Phil Friel @ Nov 12 2007, 07:48)

I rip to WAV and keep the original non-normalized WAVs as backups on a separate hard drive.
From these copies, I convert to FLAC...
You can safely convert to FLAC and discard the WAV-files. The data is the same. When you decode a FLAC, the file is the exact same as you started with (hence the term "lossless")
When you created the FLAC, you can apply ReplayGain. I have no idea if MediaMonkey supports it, but both foobar2000 and Winamp does these days.
QUOTE(Phil Friel @ Nov 12 2007, 07:48)

From these copies, I convert to FLAC for use in MediaMonkey, Traktor 3, and on my Cowon iAudio X5, and to WMA Lossless for use in SAM Party DJ (doesn't support FLAC - yet - when it does, I can get rid of the WMAs).
At this stage you already has a lossless copy available. Why not just encode to lossy wma files until FLAC is supported?
QUOTE(Phil Friel @ Nov 12 2007, 07:48)

And, as a DJ, I tend to organize my music more on an individual song basis rather than on an album basis. Would I be right in assuming that this method of ripping makes AccurateRip useless for my needs?
No, AccurateRip helps you determine if your rip matches the rip other people have made. This has nothing to do with the organisation.
QUOTE(greynol @ Nov 12 2007, 08:10)

The ability to successfully rip a copy-protected lies in the drive, not the software.
Not always, for some Copy protected CDs (R13 labels them as Defective by Design) they have the false second session in the TOC. A program can help by forcing the first session, but the deliberate wrong lead in or out from the false TOC will cause problems for CD drives which cannot read into the lead in or out.
greynol
Nov 12 2007, 11:04
Right, I forgot about that type.
Is what you're describing the same protection that EAC used to be able to circumvent until Andre was forced to remove the feature by the German gov't as of V0.95b4 and the same protection that cannot not stand up to a black marker? What you described sounds slightly different to me.
Edit: There's also the situation where an enhanced CD can install software that cripples your ability to extract audio amongst other things. This is another example where the drive doesn't make a difference.
Phil Friel
Nov 12 2007, 14:36
QUOTE(greynol @ Nov 12 2007, 08:10)

No. AccurateRip works on a track-by-track basis. Ripping an entire album is not necessary.
Thanks for verifying this (I also asked this question in another thread). This is very good news.
QUOTE
The ability to successfully rip a copy-protected lies in the drive, not the software.
Mnm... then how come I've been unable to copy those pesky copy protected CDs, despite trying them in a variety of drives? They can't all have the same problem (inability to bypass the copy protection).
QUOTE
I'm guessing you're interested in other people's opinions besides Spoon and myself since I've already given my reasons as to why not to use foobar and Spoon is the author of dBpowerAMP. I think he is justified in believing he has created the best program of the three and for drives that provide C2 pointers I have to agree with him.
Nope, I'm interested in all opinions, but particularly yours and Spoon's, as you guys seem to be the resident gurus around here, and usually know what you're talking about. I totally trust you both to give me as unbiased (as possible) opinions. In particular, Spoon, as author of dbPowerAmp, is in perfect position to explain what his software can and cannot do, and how it compares to EAC. I don't consider this a competition between the two, and will certainly use both in my "toolbox" if different situations call for one program or the other.
As it is, I'm VERY impressed with what I've seen so far of dbPowerAmp, and will certainly be paying the ridiculously small registration fee (worth it at many times the price). Spoon deserves the financial support, and it's certainly in all of our best interests to encourage such a developer to continue with his work.
Phil
>EAC used to be able to circumvent until Andre was forced to remove
> the feature by the German gov't
No one forced him, he took the decision. We have taken the decision that our software does no different than a normal cd player would so would challenge any DCMA take-down in the courts, it is not effective copy protection.
> There's also the situation where an enhanced CD can install
>software that cripples your ability to extract audio amongst other things
Yes, having the ability to disable the autorun is a must.
-------
@Phil try ripping direct to a lossless format (not wave), no need to rip to wave and you will have all the ID Tags present.
odyssey
Nov 12 2007, 15:41
@Spoon: A couple questions after trying R12:
1. If I rip a clean disc, it seems to perform a burst read followed by a secure read. This takes a lot longer than EAC burst test/copy.
2. How can I be sure that a rip was perfect without AccurateRip information? Sometimes I see "i" along "Secure" and sometimes just a checkmark. However usually a rip with the "i" won't match the CRC if I re-rip. Can I be sure that it's "Secure" when the checkmark is there?
Phil Friel
Nov 12 2007, 16:16
QUOTE(odyssey @ Nov 12 2007, 08:27)

I wouldn't do that. Wavegain is a lossy process. You reduce the SNR ratio (given you want the highest quality, that seems to defeat the purpose)
Wavegain is TECHNICALLY lossy. But (correct me if I'm wrong), since WAV files contain a lot of empty space, the Wavegain information can be saved in the "empty bits", without discarding any of the song information, so there is no deterioration in the quality of the music. Lossless codecs such as FLAC can likewise discard lots of the useless/empty bits in WAV files (saving space), while still remaining lossless. If I'm wrong in this assumption about Wavegain, please do let me know.
QUOTE
You can safely convert to FLAC and discard the WAV-files. The data is the same. When you decode a FLAC, the file is the exact same as you started with (hence the term "lossless")
That will be the end objective, once I've finished ripping my entire collection. Get rid of all the WAVs once they're all converted to FLAC. I will still want a second hard drive, preferably on a different computer (or an external drive) to have a secondary (duplicate) back-up FLAC archive. I've learned a long time ago what hard drive failure can cost in data loss. Besides, FLAC is preferable to WAV in that it supports tagging, and will save quite a large chunk of disk space compared to WAV when it's a large archive (one third or more of a 500GB hard drive is a considerable saving).
QUOTE
When you created the FLAC, you can apply ReplayGain. I have no idea if MediaMonkey supports it, but both foobar2000 and Winamp does these days.
Yes, MediaMonkey supports Replaygain, and lots of other goodies. But I prefer the method used by Wavegain and MP3Gain - writing the data directly to the file - to the usual Replaygain method - writing the metadata to tags which can be read in "compatible" programs or hardware. The first method (written direct to file) will work everywhere. The second may not. I know the "written direct to file" method is irreversible, but if done right first time around, this should not matter. And if things go wrong, that's where the backup files are a life-saver. This is why I ALWAYS work on a copy of the target file to begin with. I can always get rid of unnecessary duplicates when I'm done.
QUOTE
At this stage you already has a lossless copy available. Why not just encode to lossy wma files until FLAC is supported?
Because I don't want to play lossy files at the disco/club (or anywhere else), and the only form of lossless that SAM Party DJ supports (so far) is WMA Lossless. I only use them in this one program on a laptop, they will only make up about 5% of my entire music collection, and there will also be FLAC copies of the same music on my desktop. Once SAM Party DJ starts supporting FLAC, I can just delete all the WMA Lossless versions and use the FLAC ones instead.
QUOTE
No, AccurateRip helps you determine if your rip matches the rip other people have made. This has nothing to do with the organisation.
Thanks for clearing this up. I've never been too sure about the technical aspects of AccurateRip (never having used it).
Phil
Phil Friel
Nov 12 2007, 16:48
QUOTE(spoon @ Nov 12 2007, 21:23)

@Phil try ripping direct to a lossless format (not wave), no need to rip to wave and you will have all the ID Tags present.
Thanks Spoon. This should cut out one unnecessary stage in my ripping strategy (WAV>FLAC) by just going straight to FLAC.
By the way, I really love dbPowerAmp Converter. So easy to transcode to other formats, such as when I absolutely need to use WMA Lossless in SAM Party DJ.
Overall, because it's a proprietary format, I'm not too keen on it. But how do you rate WMA as a lossless format? Technically, being "lossless", I suppose the quality is as good as any other lossless formats. But how is it re: encoding/decoding speed, tagging capabilities, widespread compatibility with software and hardware, etc?
Phil
ArtMustHurt
Nov 12 2007, 16:52
when using accuraterip, is there a need to rip a cd in secure mode?
>1. If I rip a clean disc, it seems to perform a burst read followed by a
>secure read. This takes a lot longer than EAC burst test/copy.
Should be no slower than EAC (if not using the ultra passes). The first pass would end if had an AR match. If no AR match then another pass is done, exactly the same time as taken for test / copy.
>Sometimes I see "i" along "Secure" and sometimes just a checkmark.
The i is warning that sectors had to be re-read.
> However usually a rip with the "i" won't match the CRC if I re-rip.
>Can I be sure that it's "Secure" when the checkmark is there?
2 possibilities, 1 the drive is setup wrong somehow and the secure read is being effected by the drive cache, or 2 your cd + drive combination has given a consistant error, these are difficult to defeat (if not using c2), ultra passess varying speeds helps on some drives, your best bet is to try the rip on another drive.
odyssey
Nov 13 2007, 07:57
QUOTE(spoon @ Nov 12 2007, 23:53)

>1. If I rip a clean disc, it seems to perform a burst read followed by a
>secure read. This takes a lot longer than EAC burst test/copy.
Should be no slower than EAC (if not using the ultra passes). The first pass would end if had an AR match. If no AR match then another pass is done, exactly the same time as taken for test / copy.
It seems to rip as Ultra secure for the 2nd pass. Is it a wrong setup?
QUOTE(spoon @ Nov 12 2007, 23:53)

>Sometimes I see "i" along "Secure" and sometimes just a checkmark.
The i is warning that sectors had to be re-read.
> However usually a rip with the "i" won't match the CRC if I re-rip.
>Can I be sure that it's "Secure" when the checkmark is there?
2 possibilities, 1 the drive is setup wrong somehow and the secure read is being effected by the drive cache, or 2 your cd + drive combination has given a consistant error, these are difficult to defeat (if not using c2), ultra passess varying speeds helps on some drives, your best bet is to try the rip on another drive.
Is it common for Lite-On drives? I already experienced something like this with my old NEC drive, but the LiteOn never caused trouble in EAC.
Another example: Recently I bought 2 used CD's with light scratches. Feeding them to dBa, made it want to rerip over 10000 frames for one track, and on the other CD it didn't get any track correct! When I put both into EAC, with disabled cache and disabled C2, they were read correctly immediately.
>10000 frames for one track
That is probabbly the entire track, I have seen drives rip a track with a drive induced offset, which is gone the next time, it is a drive failure, EACs read / re-read of the small sections perhaps would not pick this up, not sure though (it is hard to determine what is going on, it is as though the accurate stream has failed, perhaps accurate stream keys off a section of the cd and if the cd has scratches).
If you are using c2, then only 1 ultra pass is needed normally.
>But how do you rate WMA as a lossless format?
WMA Lossless has its problems (see at the end):
http://www.hydrogenaudio.org/forums/index....showtopic=50907
Martin H
Nov 13 2007, 12:55
QUOTE(ArtMustHurt @ Nov 12 2007, 23:52)

when using accuraterip, is there a need to rip a cd in secure mode?
No, as long as AR verifies the rip then there's no need for secure mode at all. Also, if it's not yourself which have submitted the AR report earlier, then a confidence of 1 is enough.
SamHain86
Nov 13 2007, 13:30
QUOTE(Martin H @ Nov 13 2007, 19:55)

No, as long as AR verifies the rip then there's no need for secure mode at all. Also, if it's not yourself which have submitted the AR report earlier, then a confidence of 1 is enough.
Even if you submit AccurateRip results, it has a computer ID that prevents your previous rip from being part of the confidence interval.
http://www.hydrogenaudio.org/forums/index....st&p=523366The lack of AccurateRip is my first reason for not using FooBar2000. The next is that would not be able to use REACT like I do through EAC. Do not get me wrong, FB2K is my only media player and audio swiss-army knife, but I will not use it for ripping.
greynol
Nov 13 2007, 14:19
QUOTE(SamHain86 @ Nov 13 2007, 11:30)

Even if you submit AccurateRip results, it has a computer ID that prevents your previous rip from being part of the confidence interval.
http://www.hydrogenaudio.org/forums/index....st&p=523366I'm not certain that this is entirely fool-proof and have seen it suggested that simply using a different drive can circumvent this. Still, an AR match to only your previous submission is really no less "secure" (depending on how you want to define it) than performing test and copy.
QUOTE(SamHain86 @ Nov 13 2007, 11:30)

FB2K is my only media player and audio swiss-army knife
http://www.hydrogenaudio.org/forums/index....showtopic=49894
Martin H
Nov 13 2007, 17:24
QUOTE(SamHain86 @ Nov 13 2007, 20:30)

Even if you submit AccurateRip results, it has a computer ID that prevents your previous rip from being part of the confidence interval.
http://www.hydrogenaudio.org/forums/index....st&p=523366Ohh, i didn't knew that - Thank's for the info, mate

QUOTE(greynol)
Still, an AR match to only your previous submission is really no less "secure" (depending on how you want to define it) than performing test and copy.
Good point

I should of course have mentioned that also in my explenation...
answer is inertia. Before foobar had ripping capabilities, eac was the only game in the town that you could set up to do lame vbr. Imo, EAC only makes explicit what other rippers already have, stuff about disc caching and and gap detection, etc.
Plus, it's easier to input track names with eac than with foobar. I've never had a foobar ripped disc or even an itunes ripped disc exhibit behaviors of a messed up rip.
Phil Friel
Nov 13 2007, 19:40
QUOTE(spoon @ Nov 13 2007, 15:50)

Thanks for this link. Fascinating stuff.
Fortunately, WMA Lossless is only a stop-gap measure until this one program supports FLAC. I'm a big fan of open formats, and dislike closed formats intensely. Every other program I use supports FLAC, and my entire music archive is being ripped to FLAC. As there doesn't seem to be any problems (so far) playing the WMAL files, things seem okay at the moment. All I have to do is wait for FLAC support.
Phil
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please
click here.