Is EAC able to safely rip all audio CDs that contain DRM malware? I have a CD infected with LabelGate, and judging by the contents of the disc as seen on Linux, as long as the autorun doesn't execute, I should be able to rip the audio successfully? I have the EAC option "Disable CD autostart while EAC is running" enabled, so is that good enough to defeat the DRM, as long as I open EAC before I insert the CD? I really don't want to end up with one of these nasty Sony rootkits on my PC just from trying to rip a CD. >:(
Yes as long as autorun is disabled you should be fine. Newer windows versions I believe have autorun disabled by default. Also the built in anti-virus should detect it as malware should it somehow attempt to run.
That's a lot of "should"s, because I don't actually have any of those CDs. But yeah just don't run any executables on the disc.
I still kinda feel it is like, if you already had Tux smiling at you, why not rip it in Linux and try to retro-verify it by CUETools or something else?
If the problem is that it refuses to verify and you want to try another ripper, then ... sure, valid question.
Another option I guess is to rip it in a VM, connecting the real CD reading device to that VM
Put this on a USB key and boot it
https://slackware.nl/slackware-live/slackware64-15.0-live/slackware64-live-15.0.iso
Then use cdparanoia
I still kinda feel it is like, if you already had Tux smiling at you, why not rip it in Linux and try to retro-verify it by CUETools or something else?
I considered this, but I thought there were no secure rippers under Linux, unless you try to run EAC or CUETools under WINE. Does cdparanoia have offset correction? If not, what are the odds that I'd be able to verify the rip after the fact with CUETools?
Does cdparanoia have offset correction? If not, what are the odds that I'd be able to verify the rip after the fact with CUETools?
I have no idea of what offset is in CD rip but part of the man page talk about it
-t --toc-offset number
Use this option to force the entire disc LBA addressing to shift by the given
amount; the value is added to the beginning offsets in the TOC. This can be
used to shift track boundaries for the whole disc manually on sector granular-
ity. The next option does something similar...
-T --toc-bias
Some drives (usually random Toshibas) report the actual track beginning offset
values in the TOC, but then treat the beginning of track 1 index 1 as sector 0
for all read operations. This results in every track seeming to start too late
(losing a bit of the beginning and catching a bit of the next track). -T
accounts for this behavior. Note that this option will cause cdparanoia to
attempt to read sectors before or past the known user data area of the disc,
resulting in read errors at disc edges on most drives and possibly even hard
lockups on some buggy hardware.
-O --sample-offset number
Use this option to force the entire disc to shift sample position output by the
given amount; This can be used to shift track boundaries for the whole disc
manually on sample granularity. Note that this will cause cdparanoia to attempt
to read partial sectors before or past the known user data area of the disc,
probably causing read errors on most drives and possibly even hard lockups on
some buggy hardware.
The span argument may be a simple track number or an offset/span specification. The
syntax of an offset/span takes the rough form:
1[ww:xx:yy.zz]-2[aa:bb:cc.dd]
Here, 1 and 2 are track numbers; the numbers in brackets provide a finer grained off-
set within a particular track. [aa:bb:cc.dd] is in hours/minutes/seconds/sectors for-
mat. Zero fields need not be specified: [::20], [:20], [20], [20.], etc, would be
interpreted as twenty seconds, [10:] would be ten minutes, [.30] would be thirty sec-
tors (75 sectors per second).
When only a single offset is supplied, it is interpreted as a starting offset and rip-
ping will continue to the end of the track. If a single offset is preceeded or fol-
lowed by a hyphen, the implicit missing offset is taken to be the start or end of the
disc, respectively.
I've always simply use
cdparanoia -B
or something like that and all was ok.
* CUETools can retro-verify across offsets. If there is only an ARv2 entry to find, you may have to enter the offset manually - but CUETools will suggest for you.
* https://www.dbpoweramp.com/perfecttunes.htm - from the creator of AccurateRip - checks also ARv2 across offsets.
If you want to, you can use CUETools to convert with offset correction - but you might have to enter it manually if CUETools doesn't find it.
Also, for secure ripping ... how is https://github.com/whipper-team/whipper these days?
Whipper looks interesting, but I don't know enough about Linux to install it, since it isn't available in my distro's repositories, and the installation scripts are giving me multiple errors. I guess I'll try abcde.
In case anyone else has this problem, I found a workable solution. I used abcde to rip the disc in Linux.
abcde -1 -o flac -a default,cue
This rips the audio session of the disc to one giant FLAC file and creates a cue file of the disc structure. I then copied these files to Windows and looked up my CD drive offset in the AR database:
http://www.accuraterip.com/driveoffsets.htm
Finally, I used CUETools to apply the drive offset and split the disc backup into individual WAV files that I could process the way I normally handle CD rips. The rip now correctly verifies against CTDB and AR, and I don't have any LabelGate malware on my PC. :)
You can config abcde to apply a given offset: https://0f5f.blogs.minster.io/2014/09/precision-audio-ripping-with-abcde/
And even when you don't have the offset, you can try to run CUETools on the .cue file to verify, and the output will find or suggest offset.
Thanks for the tip. I may modify the abcde configuration file if I ever have to rip another CD on Linux. I would not trust the offsets reported by CUETools, as it almost always reports multiple alternative offsets with no indication as to which one is the correct one.
I would not trust the offsets reported by CUETools, as it almost always reports multiple alternative offsets with no indication as to which one is the correct one.
The EAC log only presents the AccurateRip results that had a matching
corrected offset to yours, whereas CUETools gives you this information (the results directly below the [AccurateRip ID: xxx] found.) as well as any other rips of that disc that may have used different offsets. Those other offsets could have been from different disc pressings or from other rips that differed in corrected offset to yours.
None of the logs are telling you which offset is correct - it's the matching rip numbers that give you this indication - they're just presenting other rips relative to yours.
I would not trust the offsets reported by CUETools, as it almost always reports multiple alternative offsets with no indication as to which one is the correct one.
The typical scenario is the following
* CUETools reports multiple offsets because there are multiple pressings with the same audio but different offsets
* Those different offsets are "arbitrarily" applied write offsets in the process of burning a CD master; just as different drives have different read offsets, different writers have different write offsets
* Although only one matches your particular pressing, nothing says that yours is "more correct" relative to the original file than another. Basically, if it matches with an offset of N, then someone has ripped the same audio as you.
There are nuances to this. Say if most pressings have offsets up to a thousand, and then there is one pressing that is waaay off, one might suspect that it has been generated by ripping a CD with big offset, writing a CD with big offset, adding up to something that would not have happened in one single process. Maybe even that is someone's CDR copy that they later ripped on a couple of computers. If that even has different audio in a few samples (CUETools might indicate), you would have a hunch that this is the one with errors introduced in the process of multiple rippings/writings/rippings.
Also if some pressing is sufficiently way off in offset, track transitions might end up wrong - and at worst, a sound (most noticable in a sharp drum hit I guess?) might cross a track boundary because the offset misplaces the track boundary.
Finally, if there are different albums (with different audio) with the same TOC, then some offsets will of course fail to verify. Same TOC occurs most often for singles, where two singles could by coincidence be precisely the same length up to the 1/75th of a second - rarely so for albums of several tracks, although I have encountered cases where different masters of the same album have same TOC.
Whipper looks interesting, but I don't know enough about Linux to install it, since it isn't available in my distro's repositories, and the installation scripts are giving me multiple errors. I guess I'll try abcde.
You also might try Fre:ac. It is available for Linux in various packages, has offset detection, AccurateRip support and pre-emphasis detection (TOC) amongst other things. It is actively developed as well.
You also might try Fre:ac.
Thanks for the tip. I assume it only supports verifying rips against AR and not submitting new results? I don't see any mention of AR or CTDB support on the website, so I guess rip verification is not a touted feature.
None of the logs are telling you which offset is correct - it's the matching rip numbers that give you this indication - they're just presenting other rips relative to yours.
I think I was a bit unclear in my original statement. I know that there is no universally correct offset; what I mean is that I ripped the disc without any offset correction using abcde, and then I tried to verify it using CUETools on a different computer. CUETools reported CTDB results that my rip was accurate, but AR did not recognise the disc at all, because the offset of my rip was uncorrected. According to the AR database, the offset of my drive is +102, which I interpret as, "My rip contains 102 extra samples that should not exist, because the drive started reading 102 samples away from where track 1 actually begins."
I used CUETools to apply the +102 offset and to split the giant FLAC file into individual tracks, at which point CUETools warned me that I would be deleting 102 samples, as expected. Now when I verify the WAV files I split, both CTDB and AR report that my rip is accurate, because AR can only verify a rip that has offset correction.
Nowhere in the CUETools results did it tell me that I needed to apply an offset of +102 to account for the read offset of my CD drive. Yes, CUETools suggests alternative offsets in the results, but it doesn't say which offset is correct for my particular CD drive. I had to look up my drive model in the AR database to get the +102 number that I needed. That's what I meant about "not trusting" the CUETools results. In order to properly verify a rip, you must account for your drive's read offset, and CUETools can't tell you what it is when you ripped the CD on a different computer. The AR database of drive offsets can.
You also might try Fre:ac.
Thanks for the tip. I assume it only supports verifying rips against AR and not submitting new results? I don't see any mention of AR or CTDB support on the website, so I guess rip verification is not a touted feature.
Verifying against AR is indeed supported by Fre:ac. Submitting I'm not sure, but I don't think so (yet). Currently there is no CTDB support, it was requested but not implemented (yet).
Nowhere in the CUETools results did it tell me that I needed to apply an offset of +102 to account for the read offset of my CD drive. Yes, CUETools suggests alternative offsets in the results, but it doesn't say which offset is correct for my particular CD drive.
If you try another alternative than +102, and get an AccurateRip match, it means that you have verified it against a different pressing. As you don't know which pressing is closest (in terms of offset) to the original file, that is equally good (
at least!) - sure some samples must have been cut off at the beginning/end to achieve that, but AccurateRip does cut away a few samples at the end anyway.
+102 with an AR match will get you: file sent to CD writer #1 which applies offset P, CD is pressed, played in your drive that applies -102, +102 zeroes out the latter - but does not zero out the "P", which is unknown.
+xyz with an AR match will get you: file sent to CD writer #2, which applies offset Q etc - and all for sudden you are matching the output from CD writer #2, which is Q-P off the output from CD writer #1.
But you don't know which one is closer to the original file.
So then that
"at least": if anything, a match against something else than 102 will verify that your rip is the same as a different pressing; telling you that it is unlikely that anything wrong happened after the file was sent to neither #1 nor #2. If they differ in only a few samples, then some bits must have been altered either in manufacturing process #1 or in manufacturing process #2, which kinda "is a warning sign". (I have seen differences like that around -84 dB or -90 dB or so and around track boundaries, meaning that some digital near-silence with only dither has been zeroed out.)
+102 with an AR match will get you: file sent to CD writer #1 which applies offset P, CD is pressed, played in your drive that applies -102, +102 zeroes out the latter - but does not zero out the "P", which is unknown.
+xyz with an AR match will get you: file sent to CD writer #2, which applies offset Q etc - and all for sudden you are matching the output from CD writer #2, which is Q-P off the output from CD writer #1.
But you don't know which one is closer to the original file.
I don't understand your point. Why would I use +xyz offset when I know that the offset of my drive is +102? There is no reason to try any other value since the correct value is known and will give the best result for this particular drive on all rips. AFAIK that's the whole point of having a database of CD drive read offsets.
I don't understand your point. Why would I use +xyz offset when I know that the offset of my drive is +102?
To get an AR hit. Wasn't that the purpose?
There is no reason to try any other value since the correct value is known and will give the best result for this particular drive on all rips.
So if your pressing is not in the database, but some other pressing is - then you say that the "best result" is to avoid verifying it and posting on HA on why you refuse?
AFAIK that's the whole point of having a database of CD drive read offsets.
That is the old and insufficient way. Offset correction was implemented before one realized the need for cross-pressing verification. The latter came about around 2010 or so.
I think I was a bit unclear in my original statement. I know that there is no universally correct offset; what I mean is that I ripped the disc without any offset correction using abcde, and then I tried to verify it using CUETools on a different computer. CUETools reported CTDB results that my rip was accurate, but AR did not recognise the disc at all, because the offset of my rip was uncorrected.
I've never seen that behaviour before as the AccurateRip ID is based on the discs layout (TOC) so the offset used has no affect. I just ripped a disc with the correct offset (+6) and then again with an incorrect offset of +600 with EAC. Running both images through CUETools produced the same output, except obviously the offsets were different in the AccurateRip results.
The correct rip produced
[AccurateRip ID: 0011590f-008dc7c1-9b0dcc0b] found.
Track [ CRC | V2 ] Status
01 [74a308c0|f823650c] (200+200/404) Accurately ripped
02 [22770025|b6ebba80] (200+200/404) Accurately ripped
03 [23a8ac4f|1b4f4b30] (200+200/404) Accurately ripped
...
Whilst the incorrect offset produced:
[AccurateRip ID: 0011590f-008dc7c1-9b0dcc0b] found.
Track [ CRC | V2 ] Status
01 [4a5640cb|d2115bf7] (000+000/404) No match
02 [d9d496d2|c5b4c939] (000+000/404) No match
03 [f5363be8|dae8b933] (000+000/404) No match
...
Offsetted by -594:
01 [74a308c0] (200/404) Accurately ripped
02 [22770025] (200/404) Accurately ripped
03 [23a8ac4f] (200/404) Accurately ripped
-594 being the difference in the offset used (600) and the drives actual offset (6).
To emulate without the need for ripping, just verify an image in CUETools then modify the offset in CUETools and verify again and you should see that the AccurateRip ID is the same and the same results are produced (under different offsets).
I don't know if abcde has anything to do with this odd behaviour?
I used CUETools to apply the +102 offset and to split the giant FLAC file into individual tracks, at which point CUETools warned me that I would be deleting 102 samples, as expected. Now when I verify the WAV files I split, both CTDB and AR report that my rip is accurate, because AR can only verify a rip that has offset correction.
As stated above that's not the case, but did the verify passes (pre and post offset correction) produce different AccurateRip ID's?
Nowhere in the CUETools results did it tell me that I needed to apply an offset of +102 to account for the read offset of my CD drive. Yes, CUETools suggests alternative offsets in the results, but it doesn't say which offset is correct for my particular CD drive.
CUETools doesn't attempt to tell you how to fix your rip given your particular cd drive and your particular disc because that's impossible! How would it know what drive was used to rip the disc and if an offset was used, and how does it know exactly what disc was ripped. I guess if a log existed it could try and parse that, but that would be messy, and would it have to produce a corrected log alongside the fixed files.
I had to look up my drive model in the AR database to get the +102 number that I needed. That's what I meant about "not trusting" the CUETools results.
Alternatively just open CUERipper, as that will show you the correct offset.
So it sounds more like a misunderstanding of what CUETools is telling you, as the results can absolutely be trusted - unless of course you've seen mention somewhere that it does tell you what offset to apply to fix the rip for your particular cd drive and cd pressing?
In order to properly verify a rip, you must account for your drive's read offset, and CUETools can't tell you what it is when you ripped the CD on a different computer. The AR database of drive offsets can.
In the above sentence, if you'd said instead "In order to properly
correct a rip" then I'd agree 100%, but verification is different from correction. It IS verifying that your rip is or is not accurate.
It sounds like we just have a different understanding of "verify" :-)
AFAIK that's the whole point of having a database of CD drive read offsets.
That is the old and insufficient way. Offset correction was implemented before one realized the need for cross-pressing verification. The latter came about around 2010 or so.
I don't understand this either. Are you saying that there's an alternative to setting your drives offset?
Are you saying that there's an alternative to setting your drives offset?
Essentially yes, but I don't recommend it - it would be at odds with how EAC/dBpoweramp & friends work.
But here we had to do with an already ripped image. Well we had to do with a malware-infested CD that, to be safe, was ripped on Linux - and because the user did not set offset upon ripping (though it is possible), then what to do? Get an AccurateRip verification.
Which could be against the same pressing or against some other pressing.
But here is the point: of two CDs contain the same audio, but different offsets,
nothing says that yours is the "correct" one. (I'm not sure if there even exist CD writers with an offset of zero.)
But here is the point: of two CDs contain the same audio, but different offsets, nothing says that yours is the "correct" one. (I'm not sure if there even exist CD writers with an offset of zero.)
So we're really just talking about the offsets introduced by the writers to create the CD masters here, and your definition of "more correct" is simply the one that was produced by the writer with the smallest offset (that we can't know)?
Given we're not talking about the audio content itself here (as that's the same on all pressings), the fact that the OP knows his drive offset is 102 (to a standard which I appreciate was debated some time ago to actually be 30 samples out) then it's definitely more correct to fix his rip with 102, as we're ripping a disc, not the original pre-mastered content.
But if your particular pressing is not in AccurateRip, do you want an AccurateRip check or do you not?
I do. I surely rip with offset correction, but a substantial part of my CD rips failed AccurateRip when they were ripped - in the age before cross-pressing verification.
(Offset correction as per the drive could have been done in the cdparanoia config file.)
-594 being the difference in the offset used (600) and the drives actual offset (6).
I guess my question is: suppose you aren't using EAC and don't know what your drive offset is. The AR results will probably show you at least one result that says "offsetted by 6", because that's your drive's offset; however, the AR results may also show you "offsetted by 14" or some other number, because your drive's offset is 6, and that particular pressing was written with an offset of 8. If you don't know what your drive's offset is, how are you supposed to pick the correct offset for your drive from the AR log if the disc has multiple pressings with different offsets?
As far as I can tell, you can't. You have to look up your drive's offset in the AR database in order to know which offset number to pick if your disc has multiple pressings with different offsets. The only way to use the AR log to find your drive's offset is if you rip a disc that has only one pressing (or multiple pressings that all use the same offset).
To emulate without the need for ripping, just verify an image in CUETools then modify the offset in CUETools and verify again
I used this method to verify my rip. I changed the CUETools offset to 102 and then verified again, and then AR recognised the disc. I then used the encode mode to split the tracks with the 102 offset applied so I'd get the same WAV files as if I had ripped with the correct 102 offset originally.
By "recognised the disc", I mean I did not see this:
[AccurateRip ID: 0011590f-008dc7c1-9b0dcc0b] found.
Track [ CRC | V2 ] Status
01 [4a5640cb|d2115bf7] (000+000/404) No match
02 [d9d496d2|c5b4c939] (000+000/404) No match
03 [f5363be8|dae8b933] (000+000/404) No match
When I saw "no match" (or "not found" -- I don't remember which) upon trying to verify the rip with an offset of 0, I interpreted this as "not accurate" and sought a way to fix the incorrect offset. I just ignored all the other AR results saying "offsetted by x", because I don't know what to do with that information. I'd have to rip the disc again to see what the CUETools log said exactly.
I guess my question is: suppose you aren't using EAC and don't know what your drive offset is. The AR results will probably show you at least one result that says "offsetted by 6", because that's your drive's offset; however, the AR results may also show you "offsetted by 14" or some other number, because your drive's offset is 6, and that particular pressing was written with an offset of 8. If you don't know what your drive's offset is, how are you supposed to pick the correct offset for your drive from the AR log if the disc has multiple pressings with different offsets?
Absolutely, if you don't have the CD drive and/or you don't have EAC, CUE
Ripper or dBpoweramp installed then there's no way from a single verify pass of a rip to know what the correct offset for the CD drive that was used to produce that rip is. However, if you have a number of rips produced by the same drive and you run verify passes across those rips then the offset will be the common offset amongst those rips. An example of this situation came up last week on the dBpoweramp forums (https://forum.dbpoweramp.com/showthread.php?48807-Help-Request-Setup-Errors-and-Strange-Results-from-New-ASUS-BW-16D1X-U&p=212308&viewfull=1#post212308).
Most likely "+6" in that example yes.
Now suppose the user had tried two CDs of pressings that were never submitted to AR. Then nothing with the +6 would have ever showed up (which is the reason why you should not use rare CDs for determining drive read offset).
But, the rips would still have been verified as accurate rips, by the entries at -6 or the +670/+680 - and that is what you want from using AccurateRip eh?
But if your particular pressing is not in AccurateRip, do you want an AccurateRip check or do you not?
Ok, in a context different to that which was being discussed; if I had a rip from an accurately configured drive of a disc which I'd ripped maybe a couple of times and the output of which was exactly the same, I'm not sure I would change it to match another.
Absolutely, if you don't have the CD drive and/or you don't have EAC, CUERipper or dBpoweramp installed then there's no way from a single verify pass of a rip to know what the correct offset for the CD drive that was used to produce that rip is.
Thanks for confirming my suspicions. :) If I were going to use Linux extensively, I would probably go through the effort of configuring WINE and EAC, but I wasn't about to do that just to rip one disc.