Видео

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.

I dont have eac in front of me, but i believe it would be %tracknr2% - %title% Look at the legend, if "title" isnt valid its probably %tracktitle% or %song title% or something similar.

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.

If youre dragging the cover art into EAC, I would instead just drag it into the folder youre ripping to, this will guarantee it ends up there. If not, assuming youre autofilling tags - the metadata provider will not always have cover art available. If you dont see artwork in EACs cover field then it will for sure not be able to transfer to your folder. In these cases youd have to manually find art then drag it into the folder. Given metadata provider cover art is often times low res or a scanned image i opt to find digital art myself and drag it into the ripping folder instead.

EAC is finding the CD art no problem, and it's showing my album folder, but not transferring over to my device (Sony a306). Not a big deal, but it is nice to have the covert art for these rips. I've even pulled them off of the internet and dragged them into the file as well, same issue. I apricate the insight. @@sharky1112

@@rickmesta6033 It may depend on the format of the image too.

@@sharky1112 Otherwise you could have config profiles that separate by disc and album folder.

If you open your files up in a music player, tag editing software or even by inspecting them and opening preferences, are the tags present? If yes, then it's a file explorer issue. If no, then it's the "Compression" settings in EAC, in particular "External Compressor" tab, where I note pasting in the custom args, make sure this has been correctly copy and pasted. RUclips started translating descriptions automatically so it might have fucked up the parameters. As for file explorer: If you're on Windows 7 it's normal because Win7 doesn't officially support reading FLAC metadata in file explorer. You have to use a third party app to add that functionality. If you're on windows 8+ and this is happening, chances are that either your file explorer view is incorrectly setup, possibly for "general" view as opposed to detailed view or for music files. Alternatively, if you embed cover art larger than approximately 2MiB to the files a process in file explorer that reads the metadata will overflow due to the padding size and crash, no longer rendering tags in the Title, Artist, Album etc fields. Only way to fix this in particular would be to embed smaller images and for existing rips with huge embeds you'd have to both de-embed the artwork and remove the excess padding.

You only have these options because you have beginner mode enabled. Go to EAC Options -> Tools -> untick beginner mode at the bottom of the tab.

@sharky1112 thank you for the quick reply!

Nothing shown in my video can mistakenly do this. Retail CDs also can't be written over in this way. I don't know what you did, but it took multiple mistakes to pull off

1. Track quality percentage refers to the percentage of error correction that was applied to that track. It doesn't actually denote quality of the track so you can ignore any value you see here. 2. You can change the metadata or filenames of all of your files post-rip, just do not make any modifications to the contents of the .log file as this would be considered editing your log and would invalidate it. One thing to note is that if you change your filenames then they will no longer match the .cue sheet, but I can assure you that the vast majority of people sharing rips do not care about the .cue sheet no longer referencing their exact filenames and there are no rules anywhere that prevent you from uploading your rips in this state. In other words, dont sweat it if you change filenames, you don't have to modify your cue to match them. The only purpose of your cuesheet is the fact that it is noncompliant and retains your gaps.

@@sharky1112 thanks for the answers. I have two more questions if you don't mind. 1. I noticed you can verify the legitimacy of a .log file, using checklog.exe. Is there an equivalent for a .cue file? They both seem to contain unique information, how does someone pirating a cd rip make sure that the .cue file hasn't been meddled with? 2. I got "(144/146) Accurately ripped, or (2/146) differs in 7856 samples @04:18:31-04:18:42" in reference to one of the tracks in the CTDB Status section of the .log file, does this matter?

@@bussyslayer9935 theres no reason to verify the integrity of your own log files, its confirming your log was not edited - which youd know was the case cause you didnt edit it Theres no tool to detect cuesheet editing because editing your cuesheet is permitted. A noncompliant cuesheet with gaps will be formatted differrently from other cues, youd be able to see the gaps written to the cuesheet itself if you viewed it in a text editor. As for the samples not matching, that means your pressing is different from the copy you matched to in the database and is not an indicator of anything going wrong.

@@sharky1112 Additionally, you can easily fix cue sheet file names with a program like cuetools.

This is due to Windows being terrible. Your windows explorer has lower permissions than EAC does which forbids you from dragging images into EAC from windows explorer. There is a solution, and I will write it below but I would highly recommend just putting the cover.jpg into the folder you are ripping to. When you attach it on EAC all it does is go into the folder so just skip the middleman and put it there yourself. As for the solution, you will need to run a program with a context menu allowing you to access your files in administrator mode to give you the same permission elevation as EAC. Then, open the context menu and search for the cover art you want to put in EAC. Once found, drag it from this open context menu into EAC. Not worth it, right?

RUclips has been translating descriptions and removing certain characters from them for a while now - this has caused the command line parameters to sometimes be affected. -8 -V -T "ARTIST=%artist%" -T "TITLE=%title%" -T "ALBUM=%albumtitle%" -T "DATE=%year%" -T "TRACKNUMBER=%tracknr%" -T "GENRE=%genre%" -T "PERFORMER=%albuminterpret%" -T "COMPOSER=%composer%" %haslyrics%--tag-from-file=LYRICS="%lyricsfile%"%haslyrics% -T "ALBUMARTIST=%albumartist%" -T "DISCNUMBER=%cdnumber%" -T "TOTALDISCS=%totalcds%" -T "TOTALTRACKS=%numtracks%" -T "COMMENT=%comment%" %source% -o %dest% Here they are again, try pasting these in to see if that changes things. If you are on EAC V1.4 or 1.5 specifically there is an issue with the section "%haslyrics%--tag-from-file=LYRICS="%lyricsfile%"%haslyrics% -T" which would need to be removed to function as normal. If you already had exactly those parameters pasted in and you are not on 1.4 or 1.5 to have an issue with writing the lyrics metadata block, try updating your flac binary to a newer version. Some old versions (1.2.x and older) seem to have trouble encoding to flac from wav when called from EAC.

@@sharky1112 A pastebin link in the description would help.

The values pertain to the serial port order and drive number. in other words, where you plugged the drive in and how many other drives you have plugged in. Those values don't matter at all for ripping.

@@sharky1112 oh right thanks for clearing that up. also i followed the filename guide and the examples listed but i dont know how to get my various artist naming scheme to look like this (1-01) (1-02) in etc in front of the artist and title. i want the brackets next to them. how would i get that?

@@mscmxrrr (%tracknr2%) %artist% - %title% will make (01) Artist - Title