In-depth Guide to Ripping Perfect FLAC files from CD - X Lossless Decoder (XLD) (100% Logs)
HTML-код
- Опубликовано: 16 июл 2024
- This guide covers how to rip perfect .flac tracks from your CDs as well as a woring CUE sheet and .log file that will score 100%.
Requirements: MacOS 10.13+ (apparently possible with 10.11.6), CD Drive, A CD
My written guide can be viewed here: docs.google.com/document/d/1J...
Links Used/Mentioned in this Video
Download XLD from sourceforge.net/projects/xld/...
Install the XLDLogChecker plugin within the " ~/Library/Application Support/XLD/PlugIns " directory
Find your drives offset in the Accurip Database: www.accuraterip.com/driveoffse...
File/Folder Naming Convention:
%A - %T (%y) [%f]/%n %t
or (for various artist compilations)
%A - %T (%y) [%f]/%n - %a - %t
Invalid Character Replacements:
/ = ／
: = ：
? = ？
" = ''
\ = ＼
* = ＊
| = |
Note: angled brackets can't be placed in youtube descriptions but the replacements are ＜and ＞
Version of XLD used in the video = 20230416
LogcheckerPlugin used in the video = 20201230
Timestamps:
0:00 - Introduction
0:19 - Requirements
0:45 - What to Expect
1:20 - Downloading XLD
2:27 - Installing XLD
3:29 - Installing the Logchecker Plugin
5:15 - Setting Up General Tab
6:37 - Setting Up Filenaming Tab
8:12 - Setting Up Batch Tab
8:22 - Setting Up CDDB Tab
8:52 - Setting Up Metadata Tab
9:40 - Setting Up CD Rip Tab
11:08 - Finding Drive's Offset Value
14:40 - Ripping a CD with XLD 
Хобби
Note: At least one user reports being able to run XLD on Mac OS X 10.11.6 so *you may be able to get away with earlier versions than 10.13 High Sierra!*
For Windows users who stumbled on this video, don't worry! You can rip your CDs using EAC instead.
I made a guide for that here: ruclips.net/video/LkLCzfBa2gI/видео.html ~
Without a doubt this is the best tutorial I've ever watched on RUclips. Thanks a lot man!
This tutorial was so useful, complete and well done! Much appreciated!
One of the finest tutorials I have encountered on RUclips. Great work, quite complete to get the results intended. One thing, when I finished all the setup and tasks you explained, finally on clicking to start the rip, a further query window popped up for opening a disk. I thought this referred to the iinserted CD, but on trial and error (=dumb luck), figured out this was asking where to write the ripped tracks. After specifiying a location, all is going well as I write this. Many thanks!!
Considering the lack of .FLAC support by Apple, this is a must. Great and clear video; I installed XLD in one go!
Outstanding video. I’m a complete neophyte but you took me step by step through the process…ripping my first cd now….this is my first time ever not using iTunes (Apple Music ALAC)…thank you…I’ve subscribed!
Thanks so much! Super helpful tutorial!
Awesome guide, thank you. Super clear instructions and articulated just fine :-) Bless you
Thanks man! Great tutorial 🙌
Thanks a ton for taking the time to create this video. I just started ripping my CD's properly for listening on a Loseless DAP. XLD is going to work so much better than Apple Music and this will do my collection justice!
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
Dear Sharks, I am using XLD since a few days. I have searched for a long time for a counterpart to EAC, after I have changed from Windows to Mac OS.
I am German, I have left school in 1980, I don't need english language in my profession. I was able to follow your instructions very well.
Your language sounds clear, distinct and friendly. You did a very good job in your video.👍
Today, I have ripped a CD and one error message occured for one track.
Track 01 : NG (total 688 submissions)
->8 tracks accurately ripped, 1 track not
Statistics
Read error: 0
Jitter error (maybe fixed): 0
Retry sector count: 8
Damaged sector count: 0
At the end
No errors occurred
Do I despite have a broken rip?
Hey, this is fine. You most likely have a different pressing of this CD.
7 of the 8 tracks match the database, while the 8th track (because your copy is different) has a different track length and so it doesnt match.
@sharky1112 I hate to be blunt, but this video contains a very misleading error at 0:28. “If your version is below 10.13, or macOS High Sierra, you cannot use XLD” is false.
Any Mac (whether it is a Macbook, an iMac, or a Mac Mini) manufactured pre-“Late 2009” according to Apple does not support higher than OS X 10.11.6 officially, but *will* run XLD 20230627 natively.
I bring this up because I am a long time Mac user, and I use an “iMac (20-inch, Early 2008)” (quoted from About This Mac) as my daily driver.
I have the latest version of XLD installed as a backup, however I regularly use 20201123 to keep my rips consistent. I’ve never once had a problem.
To encourage users of older Macs to use XLD, please correct this with at least a pinned comment. I’m not necessarily asking you to make a brand new video as that isn’t necessary.
Note to any random person who comes across this and wants to add their two cents: This account is a barely used alt, so I will not acknowledge any responses.
Thank you.
It's great that it runs for you but it's not supposed to - at least according to the developer. I only said what I said because that's what the developer endorse(d) as far as versions go.
I'll add info to the pinned comment though, ty for the heads up.
The earliest archives of XLDs site statess "It works on Mac OS X 10.3 and later." web.archive.org/web/20100914125339/tmkk.pv.land.to/xld/index_e.html
In 2012, they changed this to 10.14 and later
In 2018/10/01 XLD became a 64bit app, stating "64-bit version requires OSX 10.6 and later. Now XLD is a 3-architecture universal binary, so 32-bit intel and PowerPC machines are still supported (10.4 and later).
It should also be mentioned that if you update to MacOS Mojave or higher XLD's logchecker plugin will no longer work correctly unless you use the 2018/10/01 build or later for anyone looking here.
Hi! I have a question and hope you can clarify. What is the max.retry count? And is it really supposed to be left at 20? On some blogs, I read that some left it at 100, I am struggling to understand what the correct option is.Hope you can help!
the max retry count refers to how many times it will attempt to read a damaged sector before moving on, realistically if it can't pull all of the data by the 20th passthrough it's very unlikely to do so by the 100th.
If you set that value to 100 it may rip something slightly better than had you left that value lower, but the tradeoff is that you will be waiting over a day for your rip to finish.
So, it's fine to chose either number. If you want a chance (however slim) to rip the problemed track(s) then set the value higher, but you will have to wait a much longer duration of time for the rip to finish.
Excellent video! I was hoping that you might go into the burning stage as I'm one of those holdovers who actually use my CDs as my music source ;) I'm trying to figure out how I can get the metadata burned into my CD copy so it can be read by my player. The CD's I've ripped so far do not display that info... and I'm curious if XLD will include the metadata in the burn and if so what step am I missing? thx!
It's possible the player you're choosing to play burned CDs is unable to read metadata. (CD-TEXT) Have you tried retail CDs in it to see if it behaves differently?
Assuming your cd player is working as intended and can read CD-TEXT, you need to find a burning software that supports writing CD-TEXT to an audio CD.
XLD does not support this. sourceforge.net/p/xld/tickets/144/ There's an active ticket that was made 11 years ago still waiting for it to be implemented .
@@sharky1112 ... thx much for the reply and for confirming that XLD isn't capable of writing CD-Text (yet ;-) ... yes... my player shows the info for any CD that has the embedded data. I use an old program called Wave Editor which is excellent for authoring CD TOC and managing Metadata... even though it's a tad cumbersome... I can always use that for the burn process... just hoping for a one app solution for this process! Cheers!
I'm using version 20230627 and I found I couldn't enter a plus in the read samples offset correction value. I have an Apple Superdrive, and ended up using 667 as the value, just didn't put the + in the value.
That should be fine, as long as there isn't a - infront of the number it should consider the offset to be + regardless
My music will end up in iTunes so im going to bring them in as AIFF, you dont add the artwork, do you add that latter of just let the player pull artwork in. In my case let iTunes bring in cover art.
It depends, if cuetools database is able to pull cover art ill add it. Otherwise, ill try to find art online and add the cover art to the folder xld rips to.
If im feeling lazy ill leave the art to be found at a later date once the rips taken place, since it doesnt affect ripping quality
@@sharky1112 Thank for a fast reply. Think I might leave them out and add latter like you do. Nice tutorial thanks.
How do I find the offset value of my drive? It is listed as purged on the data base. I'm using this drive: ASUS SBC-06D2X-U
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.
@sharky1112, what's the point of the TEST copy? Obviously, it all takes twice as long. Can I skip that? If so, where do I change the setting? Thx :)
The first time it rips your CD it will store the CRC value of each audio file to then compare against the second rip. If these don't match, referred to as a 'crc mismatch' , this implies *something* went wrong during the ripping process and the audio pulled was not the same between rips.
It can't identify what exactly is wrong, only that something is wrong.
You can disable it by going to the "CD Rip" tab and disabling the "Test before Copy" option.
@@sharky1112, just had my first experience with that. Was ripping Mannheim Steamroller and when it completed the log showed one track failed. Though it seemed a bit confused about which song it was. I noticed one song (a different one) was missing. So, I deselected all, then just selected that track and tried again. It completed. I'm assuming same thing happens if I turn off Test, you'll just notice a track is missing and you re-try that track? Thx
@@davidenglund Tracks should never be missing. It would only not appear if you failed to select it when first choosing to rip the CD or aborted the ripping process before it completed.
Only other possibility is that the track title for that particular track contains invalid characters - ones your system would not be able to generate a file for.
You can double check there isn't half-width spaces before the track title starts / after it ends by backspacing at the start/end of your track titles.
The invisible page-left symbol tends to get copied if you try to copy your track titles off of discogs directly, but if you are automatically filling the tags or manually typing them this is a non-issue and probably not the cause of the problem.
@@sharky1112, hey sometimes I see in the report that one or more tracks didn't convert without errors. But when I go play the track(s) they sound fine. Is there something else on that report that would tell you if there were enough mistakes that you should try to convert that track(s) again? Thx
@@davidenglund By report, are you referring to the .log file that gets created? It shouldn't mention anything about converting tracks. Usually, it's an additional context menu that pops up if your tracks fail to convert.
Are you sure they are playing correctly as .flac files? Or, are you instead listening to them as wav files and not realizing they are in that format?
If the files are in .flac format and they are playing correctly it should be fine to just ignore whatever error you're getting - but it shouldn't be happening in the first place.
There isn't anything to tell you when you need to try to convert again, because that's not really how converting works. It should automatically convert your wav files into the format you want, if it doesn't then it failed and you'd have to do so manually.
Thank you! 🙂