Відео

Unfortunately, yes. If you go into drive options -> drive, then enable "spin up drive before extraction" it may speed things up as many drives cannot reach their full potential without it. Secure mode reads each sector at minimum twice (in other words rips the CD twice) and more times if it encounters data it can't read. Test & Copy creates a test rip, calculates the CRC32 value of the wav files, deletes the files then creates a second copy - the copy you end up with after the rip and does the same again. The above two settings are essentially making you rip your CD at least 4 times, if not more. You have ways to speed the process up at risk of errors, if you just want a listenable copy and don't intend to share them anywhere you could change to "burst mode" and only use "copy rip" instead of "test & copy selected tracks" but you may encounter audible errors if the CD is damaged or just can't be read on first passthrough. I will note that if you have a significant amount of CDs to rip, like hundreds - and you need 100% logs so test & copy and secure mode are required for you and you have an external cd drive - I would consider using a virtual machine to run macos 10.13, installing XLD and using XLD to rip your CDs instead. XLD is on average 52% faster than EAC from some tests I ran and had others help with. EAC sucks ass ;-;

Most ripping software can do this and always has been able to do this. You chose a video for creating 100% logs and ripping perfect flac copies it's overly complicated for that reason alone.

Uh, you dont have to re-do anything though? You can always tag your rip after the rip is done. Manually tagging your files post-rip doesn't affect the quality of the files and it means nothing if the filenames/metadata doesn't match the .log file. The .log file has the CRC32 value of each track which is impossible to change without modifying the raw waveform of the audio file itself so tagging can change and it will still match,.

@@sharky1112 Thanks for the reply! I'm curious to know if you personally, you replace those characters in the filenames or in the metadata or both, or if you just let them be.

@@NullVoid95 I only replace invalid characters that windows can't handle with full width replacements. The rest, I generally tag releases exactly how they appear on the release site/booklet with stylization so I don't have to go back and fix these things since I manually entered the one I wanted when tagging.

If you are able to return that and get a full refund you should. CD drives should only cost you $15 new, $1 used. The OEM drive inside of that snakeoil monstrocity is likely worth in the ballpark of $15. Does it display as "The Brennen" as your CD drive? or does XLD output another name? If it outputs a different name, google it and you'll see how much it is. As for how to handle rips done w the drive and where to put them I'm not sure, but there should be no issue with moving it to your drive afterwards.

@@sharky1112 I don’t use the drive in “that snake oil monstrosity, I use an external drive plugged into it by Rioddas. I’ve always had cds that don’t play “right” including high end players in the past. The AccurateRip attracted me. Unfortunately after loading XLD I shut it down to load the log file and it wouldn’t open again so I’m going to have to start again. Thanks for your reply.

If the metadata provider doesn't provide a cover art, or cover art isn't one of the things you are pulling from the metadata provider you would have to manually insert a cover.jpg into the folder at some point during or after the ripping process. Googling "artist - title" site:deezer.com or site:spotify.com or apple.com, music.amazon.com/ will narrow down your search to a reasonably sized cover art from one of the popular streaming sites. Usually the digital art is better than w/e the metadata provider provides because there are rules on them which state you need to submit a scan/image of the cover art to the database.

Thank you. It does retrieve a cover image, it shows above the tracklist, but it just does writes it as a jpg in the folder.

The files are extracted in .wav and then later compressed as a final step when choosing "Test & Copy -> Selected Tracks -> Compressed" If that isn't happening and you're not seeing a "file creation error" appearing, then it's due to your "Compression settings" within the "External Compressor" tab being incorrect. Most commonly, this is due to the path to *.flac.exe being incorrect.

@@sharky1112 thank you broo,,, is done 👍

You'd select actions -> test & copy selected range -> uncompressed There's probably no point in using test & copy for this, so if you want it to go 2x faster just select "copy selected range" then pick uncompressed. Be aware WAV files don't retain tags the same way FLAC files do. External devices should be able to FLAC files and most hardware you'd be playing it on does to. So, unless yours can't I would stick with FLAC.

Sure, but I can't make such a change to an existing video :P

@@sharky1112 Actually I noticed later that you have the special characters in the notes after your video. By the way, how do you know that Paranoid and Burst modes don't result in a perfect bit-for-bit copy?

​@@ajlenze8 Paranoid mode is ancient. It does half of what 'secure mode' does (re-reads each sector twice) but, in very small blocks causing significant stress on your drive. The creator of EAC hasn't suggested using the setting since at least 2007. (Note that paranoid mode is the same as burst mode with no error correction so the same argument can apply there) www.exactaudiocopy.de/en/index.php/2007/03/15/what-is-paranoid-mode-and-why-is-it-not-recommended/ Burst mode does not have "error correction" which means that it will skip over any piece of data you can't read on your first attempt. This sounds fine because as long as the CD is brand new it should be fine, right? The problem is that optical drives have very little (if any) error correction/handling on their own. It's common for drives not to be able to read brand new discs with 100% accuracy. Generally, even on the most prestine CDs you'll notice your "Track Quality: %" will be lower than 100%. This means that error correction was applied to the rip. The lower the % the more correction was applied. In practice, when you use burst mode you are likely to encounter data that your drive can't read in one go. You will skip over said data and it will result in no longer being bit perfect but also may contain audible errors (pop/skip/clicks/static)

@@sharky1112 It sounds like you're saying that all modes COULD create an exact copy, but Secure mode has the best chance to do so, especially if there are some errors. If you had said that, I would have totally agreed, but I've seen Paranoid mode result in the same checksums as Secure mode, which means that both are reading the data the same.

@@ajlenze8 If you feel more comfortable using a setting the owner of the program advises against using and toutes as being worse than Secure Mode, by all means you should do it. While all modes can achieve a perfect copy in an ideal scenario, you are very unlikely to do so and it would be ill advised to tell people they should use a mode that takes even longer than secure mode while ruining their drive (without error correction mind you) because there is a chance it can perform correctly. Since over 70% of consumer drives (per Spoon's accuraterip results) have an accuracy of 95% or lower - the statistical likelyhood of you performing a perfect rip with any other mode is not sufficient to recommend it.

In order to get cuesheets to output in another encoding you'll need to change your locale. Being on any of the english locales will output ANSI so, change to japanese and you'll get shift-jis encoded cues instead which handles unicode characters. Keep in mind that EAC preserves the encoding of metadata submitted to the metadata provider so once and a while you'll import metadata and the cuesheet will output in some non-shift-jis format. As far as sharing these rips goes - the majority of peoples cuesheets are completely broken for unicode characters/non-latin characters and there's really no problem. The cuesheet is already "broken" when created because you're converting your files to FLAC. It only functions when the files are .wav so - people really don't look at the tags within the cuesheet, the only concern is that it retains the gaps if ever someone really wants to burn the files back to CD. When burning back to CD you'd modify the tags within the cuesheet yourself to your liking. This is to say, you can safely ignore your cuesheets tags when ripping if you're not personally burning the files back to CD. As for how to rip a single file, you choose range rip. Actions -> Copy selected range (iirc, don't have the program open rn to confirm) If you're going to rip it ""incorrectly""" per private tracker standards you may as well also not use "Test & Copy" as that will slow down the rip by 2x and, possibly change your rip settings from "Secure Mode" to "Burst Mode" to reduce your time ripping by another 2x.

Hey, input the offset +667 then rip a CD. Once done, look in your .log file for the "List of alternative offset correction values" section. Pay attention to the "absolute" and "relative" columns. If it says an Absolute of "6" and a relative of "-661" with a fairly high confidence value then there is a good chance your real offset is +6, likewise if these values are different and add up to a different number it would be that offset instead. If the confidence level is very low or non-existant then there's a good chance it's +667. You can rip several CDs to be sure that you've set it correctly, 3 is probably a good number.

@@sharky1112 Thanks. I tried this, but there is no "list of alternative offset correction values" section to be found in my .log file

It says there were no errors, but when I set it to +667, it said each track was ripped with a confidence of 1/3, as opposed to when I did with the offset value at 0, which gave me anywhere from 3/3 to 18/18, but always a full value. Not sure if that's relavant.

@@blindbluesandjazz That'd mean either either the release is not that popular and therefor can't populate data it doesnt have, or it would mean that +667 is your actual offset. Would have to rip more CDs to be sure.

​@@blindbluesandjazz So, accuraterip is actually not that accurate despite its name. You will only match with other entries in the accuraterip database if your offset value matches the submissions. This means that if your offset value is something very common like +6 it will be higher than if is a non-standard offset. The amount of people who do not configure their offset value is probably pretty high and therefor it remains 0, this would end up giving you more results with an offset of 0 than an offset of +667.

The newer the version the better the compression. It wouldnt change much else, though - some very old versions have issues converting wav to flac and cause the files to corrupt. Its a pretty niche issue, but if youre experiencing incomplete tracks that stop abruptly or tracks that wont play or your files not converting from wav to flac that would be why.

@@sharky1112 Right, thanks for the quick response. Gonna have to set it up again but I have my flac profile, at least. Pretty sure the offset on my DVD-RW is +6 too but may aswell check with a disc.

Depends, you are able to perform a range rip which will rip the entire CD into a single file. The accompanying cuesheet you create will then split the files into individual tracks within your music player. Whatever you're using needs to support the use of cuesheets and, given you are essentially just splitting the range rip into individual tracks within the music player it would be the same thing as just ripping individual tracks imo. To do a range rip, Action -> copy range then, for the cue Action -> create cue sheet -> pick the one relating to range rips, i forget what its called.

dBpoweramp is probably fine, it might just be the flac binary it ships with, or that you already had that is causing the corrupt tracks. There is known issues with some earlier versions of FLAC that can cause tracks to be corrupt. If you attempt to rip uncompressed wav files instead, they'd probably be fine. This issue also affects EAC tbh, and any other ripping software, since it is the conversion from wav to flac that is causing it. Not worried about subs lol, I just made this for my friends ^^

You can actually source lossless files from Apple Music if you have an active subscription and are capable of setting up both an android VM without google apis and a frida server. github.com/alacleaker/apple-music-alac-downloader

Not exactly, you can still enable accuraterip by using 3 "key" discs. In other words, you would need to try CDs until it says that you've entered 1 of 3 key discs, then continue until you get the "3/3" popup and the ability to enable accuraterip.

The method is irrelevent if youre using a lossy codec. Your music player likely has a built in function for ripping cds, just use that. Pristine accurate ripping and mp3 isnt possible lol

Dont think so, but you can confirm by going to drive options -> offset/speed and looking to see if the top half of this tab is greyed out, and whether or not you can enable "use accuraterip with this drive" , if its not greyed out/you cant then it isnt setup

You may be able to successfully rip the first track with secure mode by going into your drive settings, enabling "spin up drive before extraction" then, de-selecting all but the problem track. Rip that track alone to see if that changes the results. I would recommend ripping to a new directory or, moving your existing rip (or at least the existing track) to another directory. That way, if you are successful at ripping the track with no errors you can replace your errored copy with the newly ripped track. Your .log file will automatically append the second rip to it as long as you don't move it out of the directory. These rips are still considered perfect so long as you have the proof (via your log) that you did both rips. Your only other option would be to try another drive if you have one available to see if you luck out at that drive being capable of reading the disc in question. This situation is fairly common. Some drives are incapable of reading some CDs, or specific portions of specific CDs. In general, this is due to the data being stored in a very specific location on the disc that your drive is unable to read from. There is also an abandoned form of copyright protection that abuses the fact that most drives fail to read data if it is pressed in a specific way, in a specific location. You can unintentionally replicate this during the pressing process leaving you with CDs without copyright protection that also fail to rip on most drives. The only type of drives capable of reading these weak sectors are "2 sheep" drives, but the last time anybody cared about this sort of thing was the early 2000s, so drives found to be "2 sheep" are all ancient ATAPI/IDE models. web.archive.org/web/20050719080602/www.makeabackup.com/burners-sheep-2.html

@@sharky1112 Thank you very much for your response. I hadn't had the time to test your method and report the results. In short, I tried activating the "Spin Up Drive Before Extraction" option and at first it seemed to work because it reached 20% of the problematic track without the error corrector getting activated, but then it got activated and the same pattern repeated: error corrector activated, some small progress, error corrector activated, some small progress, etc. I tried waiting up until progress was at around 40% (in the test phase) but the expected time was climbing north of the hour and a half, so I decided to stop. After this I ripped the whole album in burst mode and at the very last part of the log file, on the CTDB Status column, the problem track reported a "Differs in 1336 samples @" followed by several time positions. Again checked the audio, and could not hear anything so the files remained in my PC. I guess I will try with a different drive in the future. Mine is a HL-DT-STDVDRAM GP96YW70 and, quite honestly, it has served me extremely well. Do you have a suggestion for a drive that could probably work better than mine? Thanks again for your help.

​@@TheMathFilesThere is no guarentee that the drive you buy will rip a specific problematic CD. For that reason I wouldn't recommend any one drive since you may be spending money for nothing. Unless you are specifically trying to get a "100%" log to post this rip on a private tracker, having a few rips with a lower score is not a big deal. As long as they dont have any audible defects I personally wouldn't worry. As far as drives go, when looking to buy a new one it's benefitial to reference the CD Drive Accuracy List of (year before) as that will give you a good idea of which drives perfrom better than others. forum.dbpoweramp.com/showthread.php?48320-CD-Drive-Accuracy-2022 Then, you'd also want to plug these drives into www.daefeatures.co.uk/search?htoa=Yes to see if its able to rip HTOA tracks. I think I noted in my last comment to you that the only other feature one has that is worth considering are the "2 sheep" rated drives, which are able to bypass a specific form of copyright protection that was used in the early 2000s. web.archive.org/web/20050719080602/www.makeabackup.com/burners-sheep-2.html all of these are IDE though.

Choose "copy selected range" as opposed to "test and copy selected tracks" (you could use test and copy on the selected range instead, but thats a waste of time if youre not going for a "perfect" rip

Yes, that's good.