It has been astonishing to witness the rapid development of this incredible piece of software. The responsiveness and quickness of the developer tmkk to incorporate new features into XLD has made this a true user driven application. tmkk's obvious passion and dedication to his project is evident in the extraordinary gift he has given the Mac community in XLD. To help better organize the vast amount of information being posted I will try to maintain and update a list of new feature suggestions. If a HA member decides to suggest and post a new a feature it would make sense to post it in one location. Once again thank you tmkk for this monumental achievement in Mac software development.
After reading this thread please check the XLD Master Thread List (http://www.hydrogenaudio.org/forums/index.php?showtopic=66074) for other important XLD threads.
Click here to view (http://farm4.static.flickr.com/3010/2890249662_9927d3c966_o.gif) the Mac CD Ripper Comparison Chart to familiarize yourself with XLD's feature base.
Feature Suggestions
Allow album art to be automatically saved to output folder as a jpg instead of being embedded in output file(s).
I will implement this, but priority is low.
Quote from tmkk XLD developer
I would love to be able to convert whole folders and nested subfolders of audio files. Currently, you have to drop the audio files themselves on the application.
I will implement this feature.
Quote from tmkk XLD developer
Ability save 10 ripping presets based on the selections of the four preference tabs, this feature would include different drive models used on a system. Example Preset 1 SONY DVD RW DW-D150A would recall the four preference tabs assigned to it. Preset 2 HP 7500 Plus would recall the four preference tabs assigned to it. Preset 3 HP 7500 Plus would recall the four preference tabs assigned to it. In this feature a drive should have the ability for several preset settings base what is selected in th four preference tabs for instance in our example Preset 2 may have FLAC with CDParanoia with log report. ect. while Preset 3 has selected Lame MP3 without CDParanoia with no log report ect.
Automatic detection of the "Read sample offset correction values"... Unlike Windows, Macs are built with very controled hardware and it would not be difficult to build a database of CD/DVD drive offsets for different models of Mac drives...
Add ability to READ noncompliant cue sheets... Currently they can be generated during ripping (and that's GREAT!), but it would be nice if we could read them too...
These features are added (or already in) my working list. The upper one has higher priority (or easy to implement).
Quote from tmkk XLD developer
An option to choose to rip by sector number and/or duration, à la cdparanoia III 9.8. Say you want to rip only the first 1:02 seconds of a track... That sort of thing.
Option for it to automagically query its databases for metadata, rather than having to be told to go look.
These features will be implemented (priority is low).
Quote from tmkk XLD developer
Add option to automatically save a M3U file, for the folks who need them.
Add option to "Always ask" in the Output Directory preferences...
MacMelo contacted tmkk about these features and tmkk told him these will be implemented as soon as other more important ones are done.
Completed Addition of Suggestions and Development Explanations
XLD now always saves a logfile in the same directory as ripped files
Features added to XLD Version 20080925:
Previous versions of XLD didn't, but would it be possible to copy over ALL tags when transcoding from one format to another? Even non-standard ones?...Or at least the tags that iTunes can/will append to files it recognises (e.g. ALBUMSORTORDER, ITUNESCOMPILATION, etc.)
ALL is impossible, because the way to store the entry of metadata item in MP4 metadata and ID3 tag (4 bytes binary) differs from the way in ape tag and vorbiscomment (unlimited(?) length text). If you want me to do this, please list the all tags that should be supported by XLD.
Quote from tmkk XLD developer
Also, since the option exists to have XLD add the file to the itunes library, there's no need to have a 2nd copy of the file. This occurs when itunes copies the file when adding to its library and then the file created by XLD is left over. It would be nice to have an option to automatically delete the second copy of the file that XLD creates if you have itunes set to copy files into the library.
I think this option is a little dangerous, because adding to the library sometimes fails due to simultaneous access during multi-threaded conversion (and iTunes does not support the all formats from XLD).
Quote from tmkk XLD developer
Give us an option to automatically not use CD Paranoia when there is an AccurateRip DB entry present. In other words it shoudl function how DBPA CD Ripper does... Rip in burst mode first, then if there is a mismatch switch over to secure ripping. Right now with my current drive I am seeing a rip speed of less than 2.0x
To add that option is easy, but it's complicated to implement a feature to switch automatically to another mode. I may implement, but it will take a long time. Until then, please do manually.
Quote from tmkk XLD developer
Eliminiate the multiple windows. Having 3 windows open just to start ripping, edit metadata and monitor progress is rather annoying.
Currently I have no plan to change the interface.
Quote from tmkk XLD developer
Add the ability when using simultaneous codec conversion to choose the type of output for each format selected such as how the CD is to be ripped( Include pregap, Exclude pregap or Save as a single file +cue) while having independent control of the Format of filename. An example would be to rip a CD with the 1st format as FLAC file, selecting a single file +cue, with Format of filename output as %A/%T/%f/%T. The 2nd format as an AAC file, selecting to Include pregap, with the Format of filename output as %A/%T/%f/%n %t. Both formats should have the ability to share common folders in Format of filename.
The current architecture of XLD doesn't allow to do this. If this is to be implemented, it will be the distant future.
Quote from tmkk XLD developer
Place all of the AccurateRip results at the bottom of the log report instead of underneath each track listing similar to EAC. This would allow quick review of AccurateRip results!
I'll consider if there are many requests about this.
Quote from tmkk XLD developer
Indicate the setting of the "Strength of cache defeating ability" feature in the log report
Indicate which version of CD Paranoia was used during ripping in the log report
In the application window place reminder after “Exclude pregap from the output” button that you loose the ability to compare your selected tracks to the AccurateRip data base.
Logical output folder creation based on searched metadata. Example main folder=Artist, sub folder 1=Album, sub folder 2=codec type
Simultaneous Multiple Codec Conversions Example FLAC and AAC being converted at the same time to be saved in different folders labeled by the type of codec outputted
Add the cache analysis option to run on XLD
Feature added to XLD Version 20080916
Added ability to switch between using both CD Paranoia II and III.
Feature added to XLD Version 20080914 (90.0)
Update the CD Paranoia mode to the latest stable released version of III 10.2
Added "Check all items" and "Uncheck all items" in the context menu of the trac
Feature added to XLD Version 20080913 (89.0)
A "compare WAV" feature like EAC.
I can't find a clear reason to implement this feature in XLD. XLD is an audio converter software.
Quote from tmkk XLD developer
Automatic album art downloading feature now can be disabled from CDDB menu
Ability to load album art work when Gracenote tags are used without changing the Gracenote tags. Just disable all Query Items under CDDB menu except Cover Art
Added option to modify a size of padding section in FLAC encoder
Added save button in Log window
Features added to XLD Version 20080912 (88.0)
Fixing the "detect pregap" hangup on CD Extra discs on G5 (and maybe G4) machines.
Problem fixed in XLD Version 20080910
CD Writer with write offset possibly using cdr tools
Edit FLAC Metadata without reconverting the whole FLAC file
XLD is not a CD writer or tag editor, but a audio converter. The priority to implement this feature is quite low.
Quote from tmkk XLD develper
Incorporate AccurateRip submissions, so that XLD users can help the AccurateRip database to grow...
It would not be possible to submit to AR without the use of AccurateRip.dll, there are many 'attacks' on the database where rouge data is submitted (sometimes even doc files mangled into AR results), deliberate attempts to pollute the database, so we will not be opening up the submission details.
Quote from Spoon accurate developer
Regarding some of the latest features (checking existing rips against AccurateRip; offset correction of existing rips), I may be missing something, but it seems to me that a cue file is needed to use both functions. If that's so, it would be nice if we could do it even without a cue, just by dragging the FLACs to a queue window, or something like that... If I misunderstood, I apologiza... I haven't fully explored these features yet...
AccurateRip querying can't be performed without the whole length of the disc, so it is not possible with a separated track file itself.
Quote from tmkk XLD developer
Newly Suggested Features
Add to log the peak level for each track (EAC log does).
Apparently CDs from different pressings, even though from the same master, can have different CRCs. They would have the same peak levels so that info in the log could aid verification.
Add the ability to search albumartexchange.com for album art. This site has higher resolution album art images that have been cleaned up. The Album Art Exchange database of album art seems to growing at a rapid pace. I think this would a great asset to add to XLD allowing the user to get retrieve more consistent quality album art.
Ability to switch to Gracenote info if you already used freedb.
Although the Gracenote feature is fairly idiot proof once you know to have iTunes open, I'm stuck with a lot of freedb tags in XLD that I can't seem to replace with the much better Gracenote offerings.
It would be nice if XLD would save downloaded/modified metadata to its OWN database for retrieval later. As it stands, if XLD hangs during a rip, and has to be shut down, any modifications made to downloaded metadata have too be re-entered... which is time-consuming.
The ability to cancel or skip the pregap detection when mounting a disc would be nice. Maybe having the option to detect the pre-gap AFTER editing metadata, etc.
When transcoding individual files have XLD respect the Format of filename structure.
Make user definable offsets part of the auto offset function. I just got a drive that isn't included, and I really miss the nice brainless quality of the auto setting.
I'd like to suggest a "total track" field among the tags, so that when importing to audio players it will detail, for example, "Track 5 of 17." i've also found that although there is a "disc total" field, the setting does not save correctly (at least in lame mp3.) if you have the time, would you please solve this?
Ability to use customized switches under a selected format(FLAC, WavPack, Lame, Ect.)
Place the format section drop down menu in XLD's main application window(the window with decode button) to help avoid the chance of having selected the wrong format from the previous encoding session.
That is confusing many people into believing that AR is "suggesting" that changes are required. Several people have written to me asking me why the log is "suggesting" they change the offsets.
I think it would be much less confusing (and much more accurate) if the log were reworded to read as 'List of alternate offset correction values'.
A good one button "cancel" option that will get out of the endless hang situation, Also just to easily cancel a rip you just started with some wrong settings.
My external drive also disappears in the hang situations, and needs to be disconnected or restarted to show up again - if that can be fixed.
Above feature suggestions are awaiting answers on status.
Latest XLD Version 20080926 (93.3)
XLD release notes (http://tmkk.hp.infoseek.co.jp/xld/releasenotes_e.html)
Add multiple output processes a la Max. I often have occasion to go to FLAC, ALAC, and AAC and love doing it in one fell swoop with Max. More, to be able to choose different output locations for these formats.
Add multiple output processes a la Max. I often have occasion to go to FLAC, ALAC, and AAC and love doing it in one fell swoop with Max. More, to be able to choose different output locations for these formats.
tim.lance
I think that is what is meant by Simultaneous Codec Conversions. I inserted the word multiple and gave an example to hopefully clear up any ambiguity. Thanks
@macman4hire: I think it would be better to remove the "codebox" tag, so that the entire list can remain visible at all times...
Feature Suggestions:
1. Automatic detection of the "Read sample offset correction values"... Unlike Windows, Macs are built with very controled hardware and it would not be difficult to build a database of CD/DVD drive offsets for different models of Mac drives...
2. I would like to be able to save different rip presets... something like you suggested regarding different drives, but I would like to be able to save, say, 10 presets even if I have only 1 drive (1 for FLACs, 1 for ALACs, one for MP3, etc etc)
3. The simultaneous codec conversions are a must have feature... Seriously... And with the option to save to different locations, etc etc...
4. Incorporate AccurateRip submissions, so that XLD users can help the AccurateRip database to grow...
5. Add ability to READ noncompliant cue sheets... Currently they can be generated during ripping (and that's GREAT!), but it would be nice if we could read them too...
6. Regarding some of the latest features (checking existing rips against AccurateRip; offset correction of existing rips), I may be missing something, but it seems to me that a cue file is needed to use both functions. If that's so, it would be nice if we could do it even without a cue, just by dragging the FLACs to a queue window, or something like that... If I misunderstood, I apologiza... I haven't fully explored these features yet...
@macman4hire: I think it would be better to remove the "codebox" tag, so that the entire list can remain visible at all times...
Feature Suggestions:
1. Automatic detection of the "Read sample offset correction values"... Unlike Windows, Macs are built with very controled hardware and it would not be difficult to build a database of CD/DVD drive offsets for different models of Mac drives...
2. I would like to be able to save different rip presets... something like you suggested regarding different drives, but I would like to be able to save, say, 10 presets even if I have only 1 drive (1 for FLACs, 1 for ALACs, one for MP3, etc etc)
3. The simultaneous codec conversions are a must have feature... Seriously... And with the option to save to different locations, etc etc...
4. Incorporate AccurateRip submissions, so that XLD users can help the AccurateRip database to grow...
5. Add ability to READ noncompliant cue sheets... Currently they can be generated during ripping (and that's GREAT!), but it would be nice if we could read them too...
6. Regarding some of the latest features (checking existing rips against AccurateRip; offset correction of existing rips), I may be missing something, but it seems to me that a cue file is needed to use both functions. If that's so, it would be nice if we could do it even without a cue, just by dragging the FLACs to a queue window, or something like that... If I misunderstood, I apologiza... I haven't fully explored these features yet...
MacMelo I took your suggestion removing the codebox much better presentation. I added your ideas to the suggestion list. I took the liberty of combining your idea number 6. to my idea and hopefully merged them into a coherent explanation.
Well, tmkk has given us so much lately, I'd feel a bit guilty demanding more. Still, if we're going to play that game, I'd start with a few relatively minor requests:
1. Fixing the "detect pregap" hangup on CD Extra discs on G5 (and maybe G4) machines.
2. A "select all " and "deselect" all option on the track list display.
3. An option to choose to rip by sector number and/or duration, à la cdparanoia III 9.8. Say you want to rip only the first 1:02 seconds of a track... That sort of thing.
4. A "compare WAV" feature like EAC.
All of this would be quite nice to have. At the pace tmkk has been going, I'm sure we'll have all this and more very soon.
Well, tmkk has given us so much lately, I'd feel a bit guilty demanding more. Still, if we're going to play that game, I'd start with a few relatively minor requests:
1. Fixing the "detect pregap" hangup on CD Extra discs on G5 (and maybe G4) machines.
2. A "select all " and "deselect" all option on the track list display.
3. An option to choose to rip by sector number and/or duration, à la cdparanoia III 9.8. Say you want to rip only the first 1:02 seconds of a track... That sort of thing.
4. A "compare WAV" feature like EAC.
All of this would be quite nice to have. At the pace tmkk has been going, I'm sure we'll have all this and more very soon.
Pepzhez no one is demanding more! This thread is just an attempt to unite the minds of all the XLD users and to give tmkk the opportunity to further improve on the best software application on the Mac. This list is not an attempt to pressure the tmkk or the development pace. I do not code and organizing this list is something I can contribute. It is the least I can do after all the work tmkk has put into XLD. If tmkk never added another feature or line of code I am truly grateful for what he has given us. I hope you and everyone now understands my motivation for creating this list.
I placed your feature suggestions on the list. Thanks
Suggested features update tmkk emailed this information.
In the application window place reminder after “Exclude pregap from the output” button that you loose the ability to compare your selected tracks to the AccurateRip data base.
Ability to turn off the automatic art work feature.
Ability to load album art work when Gracenote tags are used without changing the Gracenote tags. iTunes will not allow you to download album artwork. The download feature in iTunes will work only after an import to iTunes.
Option to save log when using the Check file with AccurateRip feature
Option to pad FLAC files for the ability to later add album art or extra metadata
Logical output folder creation based on searched metadata. Example main folder=Artist, sub folder 1=Album, sub folder 2=codec type
Simultaneous Multiple Codec Conversions Example FLAC and AAC being converted at the same time to be saved in different folders labeled by the type of codec outputted
ability save 10 ripping presets based on the selections of the four preference tabs, this feature would include different drive models used on a system. Example Preset 1 SONY DVD RW DW-D150A would recall the four preference tabs assigned to it. Preset 2 HP 7500 Plus would recall the four preference tabs assigned to it. Preset 3 HP 7500 Plus would recall the four preference tabs assigned to it. In this feature a drive should have the ability for several preset settings base what is selected in th four preference tabs for instance in our example Preset 2 may have FLAC with CDParanoia with log report. ect. while Preset 3 has selected Lame MP3 without CDParanoia with no log report ect.
Automatic detection of the "Read sample offset correction values"... Unlike Windows, Macs are built with very controled hardware and it would not be difficult to build a database of CD/DVD drive offsets for different models of Mac drives...
Add ability to READ noncompliant cue sheets... Currently they can be generated during ripping (and that's GREAT!), but it would be nice if we could read them too...
These features are added (or already in) my working list. The upper one has higher priority (or easy to implement).
CD Writer with write offset possibly using cdr tools
Edit FLAC Metadata without reconverting the whole FLAC file
XLD is not a CD writer or tag editor, but a audio converter. The priority to implement this feature is quite low.
Regarding some of the latest features (checking existing rips against AccurateRip; offset correction of existing rips), I may be missing something, but it seems to me that a cue file is needed to use both functions. If that's so, it would be nice if we could do it even without a cue, just by dragging the FLACs to a queue window, or something like that... If I misunderstood, I apologiza... I haven't fully explored these features yet...
AccurateRip querying can't be performed without the whole length of the disc, so it is not possible with a separated track file itself.
Incorporate AccurateRip submissions, so that XLD users can help the AccurateRip database to grow...
Is this possible for 3rd party application? I'm not sure.
Add multiple output processes a la Max. I often have occasion to go to FLAC, ALAC, and AAC and love doing it in one fell swoop with Max. More, to be able to choose different output locations for these formats.
tim.lance
I think that is what is meant by Simultaneous Codec Conversions. I inserted the word multiple and gave an example to hopefully clear up any ambiguity. Thanks
Yeah, didn't sufficiently read your most excellent listing.
Heck, all I can really add is a bit of support for the noncompliant cue. I just read another thread where a poll of HA folk showed 75% archiving to individual files.
Pepzhez no one is demanding more! This thread is just an attempt to unite the minds of all the XLD users and to give tmkk the opportunity to further improve on the best software application on the Mac. This list is not an attempt to pressure the tmkk or the development pace. I do not code and organizing this list is something I can contribute. It is the least I can do after all the work tmkk has put into XLD. If tmkk never added another feature or line of code I am truly grateful for what he has given us. I hope you and everyone now understands my motivation for creating this list.
I placed your feature suggestions on the list. Thanks
Please don't get me wrong. I didn't think you were demanding anything! I had just spent some hours online with tmkk, during which he patiently and brilliantly figured out the PowerPC XLD problems I posted about in the other thread, so I just didn't want him to think that *I* was asking for more. That's all I meant.
I think tmkk is right to not make XLD bloated by including a burning program, etc. (You might want to ask the developer of Simply Burns -- great free OS X burning GUI, by the way; I tossed out the ludicrously bloated and Toast after discovering this app -- if he'd incorporate burning offsets. I still use a command line app to burn CD-Rs with a write offset, although I really can't be bothered to get picky over CD-R write offsets much these days .)
I'm sorry but I can't find XLD : each time I get a japanese html page
http://tmkk.hp.infoseek.co.jp/xld/xld-gui-20080822.tbz (http://tmkk.hp.infoseek.co.jp/xld/xld-gui-20080822.tbz)
can somebody help me getting this software somewhere?
thanks
Try:
http://tmkk.hp.infoseek.co.jp/xld/index_e.html (http://tmkk.hp.infoseek.co.jp/xld/index_e.html)
Make sure to update immediately.
Try:
http://tmkk.hp.infoseek.co.jp/xld/index_e.html (http://tmkk.hp.infoseek.co.jp/xld/index_e.html)
Make sure to update immediately.
thanks but where is the download link? I've already visited this page several times...
I might be an idiot ...
I mean the command line seems to work (but I don't understant how to rip with command line) while the first link doesn't work at all (and I guess it's the file I need) :r
thanks but where is the download link? I've already visited this page several times...
I might be an idiot ...
Being an idiot myself I can't begin to compare ...
About one third down the page is a Download section. The first item is what you want. As soon as you have XLD up and running update it.
The first link's working fine here. Which browser are you using and are you opting to save the file or open it with a helper application (The Unarchiver, S****it etc) ?
Suggested features update tmkk emailed this information.
Regarding some of the latest features (checking existing rips against AccurateRip; offset correction of existing rips), I may be missing something, but it seems to me that a cue file is needed to use both functions. If that's so, it would be nice if we could do it even without a cue, just by dragging the FLACs to a queue window, or something like that... If I misunderstood, I apologiza... I haven't fully explored these features yet...
AccurateRip querying can't be performed without the whole length of the disc, so it is not possible with a separated track file itself.
I'm not really sure if that's true, or maybe I wasn't clear... As far as I know, what I described is precisely what TripleFLAC does...
What I'm talking about is not trying to compare 1 individual FLAC file with the AccurateRip database... I'm talking about comparing 1 entire album, consisting of several individual FLAC files... Isn't that exactly what TripleFLAC does?
From what I understood so far, XLD can only do its comparisons if the album was ripped to 1 big file + cue sheet...
What I'm talking about is not trying to compare 1 individual FLAC file with the AccurateRip database... I'm talking about comparing 1 entire album, consisting of several individual FLAC files... Isn't that exactly what TripleFLAC does?
From what I understood so far, XLD can only do its comparisons if the album was ripped to 1 big file + cue sheet...
This is exactly why I hated TriplFlac. I needed to split my file into useless multiflac. I don't get why poeple who are caring about offset, want a splitted album...
I don't get why poeple who are caring about offset, want a splitted album...
This doesn't make any sense.
Why would offsets be more important for single-file images than for individual tracks?
Spoon you may be able to answer a couple of questions about AccurateRip that some members have posted in this thread.
- Incorporate AccurateRip submissions, so that XLD users can help the AccurateRip database to grow... Is this possible for 3rd party application? I'm not sure.
- Regarding some of the latest features (checking existing rips against AccurateRip; offset correction of existing rips), I may be missing something, but it seems to me that a cue file is needed to use both functions. If that's so, it would be nice if we could do it even without a cue, just by dragging the FLACs to a queue window, or something like that... If I misunderstood, I apologiza... I haven't fully explored these features yet...
AccurateRip querying can't be performed without the whole length of the disc, so it is not possible with a separated track file itself.
Thanks for you help.
I'm not Spoon, but I can answer your questions.
1) Yes. EAC is able to submit to the AR database, for example.
2) Cue sheets are only necessary if the correct disc ID cannot be generated using the tracks themselves (in the event that the pregap before the first track is greater than 2 seconds) or in the case that the disc is written to a single-file image (for the same reason: the audio data all by itself cannot generate a disc ID). In the case of enhanced CDs, more information is necessary as the cue sheets and audio data are not adequate. As for offset correction, it is absolutely necessary and has nothing to do with cue sheets. I've thrown some ideas out to tmkk about checking tracks ripped after the fact with AR without needing a cue sheet and it should work for enhanced discs as well.
For the record, I think submission to the database by XLD users is a good thing, but not for tracks that were previously ripped. I would be surprised if Spoon didn't agree with me on this.
The first link's working fine here. Which browser are you using and are you opting to save the file or open it with a helper application (The Unarchiver, S****it etc) ?
ok, thanks
Safari is THE IDIOT. Firefox is clever.
ok, thanks
Safari is THE IDIOT. Firefox is clever.
Nice. Welcome to the XLD party.
The first link's working fine here. Which browser are you using and are you opting to save the file or open it with a helper application (The Unarchiver, S****it etc) ?
ok, thanks
Safari is THE IDIOT. Firefox is clever.
I now know what you're talking about. It happened to me, too. And, yes, Safari can be rather stoopid. Next time this happens, and it will as it happens too often, right-click on the link and choose "Download linked file."
1) Yes. EAC is able to submit to the AR database, for example.
Note that EAC does so using spoon's accuraterip DLL. XLD can't do that (at the moment).
-brendan
For the record, I think submission to the database by XLD users is a good thing, but not for tracks that were previously ripped. I would be surprised if Spoon didn't agree with me on this.
Well, the vast majority of my collection runs toward the obscure, so in most cases either the disc is not in the database at all, or only has one or (at best) two submissions. Adding a second or third submission to the AR database for such cases would be beneficial, I would think.
I have no idea if the AR code would allow submissions from discs that are below a certain threshold. Say, if the disc has less than 5 submissions, AR adds the data; if that particular disc already has more than 5, AR ignores the submission. That sounds reasonable, yes?
BTW, if anyone has trouble downloading from the XLD page, it's also available for download at MacUpdate: www.macupdate.com/info.php/id/23430.
Note that EAC does so using spoon's accuraterip DLL. XLD can't do that (at the moment).
EAC also uses the DLL to check rips which XLD
can do, so I don't see the dilemma.
@Pepzhez:
I'm talking about not being able to submit data from files on your hard drive, but being able to submit from rips from your optical drive and want to also note that these rips should only be allowed using drives with the correct offset correction. Whether the titles are obscure is irrelevant. The point is to prevent information from downloads and previous rips where there is absolutely no mechanism in place to verify that the data was extracted correctly by way of offsets and gap handling as well as other issues. These are the "rules" which are already in place and have been for quite some time. As an example, if you try to upload information using a virtual drive, your results are rejected and a ban is placed on your ID.
Note that EAC does so using spoon's accuraterip DLL. XLD can't do that (at the moment).
EAC also uses the DLL to check rips which XLD can do, so I don't see the dilemma.
I think bhoar is getting at the point that XLD can't
submit data. Calculating the AccurateRip hash and retrieving the relevant hash file is trivial to implement. Getting access to the submission process hasn't been publicized. I believe Spoon has listed his reasons for this as maintaining the accuracy of the database, etc.
I have always held back on this kind of sub offset detection as it greatly increases the chances of collisions, hence the design for AR2. (for example if 2000 offsets are tested then the 1:4 billion collision is 1:4 billion / 2000). If the offset is kept constant across all tracks (ie only done once all tracks are ripped then there is less chances of collision).
The "Detect Offset" feature uses the Accurate DB as the reference. I do not see the benefit of adding these corrected files if this could possible taint the accuracy of AccurateRip DB when files are already contained in the DB. It seems like a lot of risk just to increase the confidence levels. Newly ripped CD added to AccurateRips DB make sense if the CD has never been added before or if the CD is already in the DB to increase the confidence levels. I think to have the ability to add a newly ripped CD is fine to increase DB if there is no risk of tainting the DB. The key is not to taint AccurateRips DB or it will become useless as resource. Above is quote from Spoon who is the developer of AccurateRip.
Yeah this brings up an excellent point. Even though it's a great thing to be able to check your disc against an alternate pressing when yours doesn't exist in the database, I think it would be better to submit your pressing with the correct offset so that it will be available for the next person with your pressing.
Anyway if I'm just restating the previous point, my apologies. I'm a bit slow today. Pretend I'm just thinking out loud.
Oh and when I said "rules" earlier, I'm only speaking from the impression I've gotten after discussing AR over the past couple of years. I don't pretend to speak for Spoon.
It would not be possible to submit to AR without the use of AccurateRip.dll, there are many 'attacks' on the database where rouge data is submitted (sometimes even doc files mangled into AR results), deliberate attempts to pollute the database, so we will not be opening up the submission details.
Apples global market share is 1.8% in the third quarter of this year. I seriously doubt if Mac users not being able to submit their XLD AccurateRip results to the database will negatively impact on the AccurateRip concept when 98.2% of the world will be able to submit their results. The only way I see a negative impact is if Mac users listen to some weird and obscure tunes, which is possible. Such as Steve's Silicon Sonata, Cupertino California Concerto or the Apples Adagio for Strings!
For use as a ripper, I'd like an option for it to automagically query its databases for metadata, rather than having to be told to go look.
Also as a ripper feature, creating a directory for the tracks would be a great help.
I realise in making these suggestions that XLD was first intended as a file converter, and it's only grown into being a ripper.
For use as a ripper, I'd like an option for it to automagically query its databases for metadata, rather than having to be told to go look.
Also as a ripper feature, creating a directory for the tracks would be a great help.
I realise in making these suggestions that XLD was first intended as a file converter, and it's only grown into being a ripper.
Added your first suggestion to the list. Please explain the creating a directory for tracks. Not sure what you mean.
It would not be possible to submit to AR without the use of AccurateRip.dll, there are many 'attacks' on the database where rouge data is submitted (sometimes even doc files mangled into AR results), deliberate attempts to pollute the database, so we will not be opening up the submission details.
Off-topic: Have you logged the IPs? So can you elaborate what persons or organizations might be behind those attacks? Just random idiots or actually some bigger players?
Never looked at IP addresses, luckily the database importer seems to have automatically highlighed and purged all attacks so far.
SNIP
Also as a ripper feature, creating a directory for the tracks would be a great help.
SNIP Please explain the creating a directory for tracks. Not sure what you mean.
Sorry for lack of clarity. I meant what I think is a point on your original list, I now see:
"Logical output folder creation based on searched metadata. Example main folder=Artist, sub folder 1=Album, sub folder 2=codec type"
So I'm sorry for redundancy, too.
SNIP
Also as a ripper feature, creating a directory for the tracks would be a great help.
SNIP Please explain the creating a directory for tracks. Not sure what you mean.
Sorry for lack of clarity. I meant what I think is a point on your original list, I now see:
"Logical output folder creation based on searched metadata. Example main folder=Artist, sub folder 1=Album, sub folder 2=codec type"
So I'm sorry for redundancy, too.
No problem thank you for your input.
Here are some new features for XLD included in version Version 20080912 just released today. I don't know what else to say! I will try to updated the suggested features list today. Thanks tmkk!
Version 20080912:
• Automatic album art downloading feature now can be disabled from CDDB menu
• Added option to modify a size of padding section in FLAC encoder
• Added save button in Log window
• Modified log format to show not only relative values but also absolute values for a real-time offset checking result
• Absolute values can be used for the drive offset, and relative values can be used for fixing offset of existing files.
• A real-time offset checking feature now can be used for the first and the last track
• Note that detection will fail if the first or last 5 sectors contain non-zero samples.Version
20080911:
• Fixed a problem of ALAC decoding with QuickTime 7.5.5
Version 20080910:
• Fixed a problem for reading an enhanced CD (CD-extra)
Version 20080909:
• Fixed an endian-swapping issue on some environments and CDs
Version 20080908:
• Implemented a feature to check offset in the ripping stage
• Now XLD performs a real-time offset checking while ripping, when the CD is available in AccurateRip DB. The result is written in the log if found. Note that this feature is not available for the first and the last track.
Version 20080907a:
• Improved performance of offset detection
• Supported displaying all candidates for the offset correction value
Version 20080907:
• Added feature to fix a wrong offset of the existing files using AccurateRip database
• You can detect and fix an offset from "Detect Offset" and "Save with Offset Correction..." in File menu, after opening a file (with cuesheet) that you want to fix.
• Separated drift errors from skip errors in cdparanoia statistics
• Added option to treat AccurateRip mismatch as an inconsistency in log
• Modified loading method of Sparkle.framework to support OSX 10.3
Version 20080906:
• Sorted character encoding pop-up menu by alphabetical order
Version 20080905:
• XLD now shows "[AR]" string in the titlebar of the window when a disc is available in AccurateRip DB
Version 20080904:
• Added option to avoid testing when the track exists in AccurrateRip DB
• Supported creating a cue sheet for separated track files
• You can choose type in the save dialog. Note that currently XLD can't read this type of cue sheet.
Version 20080902:
• Fixed a problem in ALAC decoder
Version 20080830:
• Added option to test before copy
Version 20080829:
• Added option to veryfy suspicious sectors
Version 20080828:
• Added option to save a log file automatically
• Improved progress view to show a speed and remaining time
Version 20080827:
• XLD now automatically recognizes inserted/ejected CD
• Supported embedding album art in WavPack encoder
• Fixed to ask output directory if the default directory is not writable
Version 20080826:
• Fixed to report correctly in case AccurateRip doesn't have informations for all tracks
Version 20080825:
• Fixed several bugs in cdparanoia routine according to the latest release
• Fixed UTF-8 NFD issue when looking up Gracenote database
• Fixed MusicBrainz query failure on PPC Mac
Version 20080824:
• Fixed a problem that XLD sometimes failed to find a CD in AccurateRip database
Version 20080823:
• Added feature to calculate an AccurateRip hash for the existing files
• Choose "Check file with AccurateRip" from the File menu.
• Fixed again an AccurateRip hash calculation for the first track
• Sorry for confusion... I hope this will be the solution...
Version 20080822a:
• Fixed an AccurateRip hash calculation for the first track with pregap
Version 20080822:
• Fixed an AccurateRip hash calculation for the first and last track
• Improved tag editor
• Supported automatic update using Sparkle
Now you need real-time offset adjustment for AccurateRip verification (EDIT: but not for the files written to your drive, which should be offset according to the correction currently entered into XLD) so that you don't have to re-rip with a different correction, or apply a correction to previously ripped files.
• Added option to modify a size of padding section in FLAC encoder
So what is all that about? I notice that the default in this new XLD FLAC padding feature is 4kb. Is there a reason to keep it at 4kb when I encode to FLAC?
Notice that the feature suggestions are disappearing form beneath the Feature Suggestions heading at the top of the list (located 1st post 1st page of this thread). Several suggested features are now placed in the middle of the list under the Addition of Suggestions and Development Explanations heading as newly incorporated features or explanations about a suggested feature and its status of being added to the XLD project. The feature suggestions list is getting smaller. tmkk is hammering away at this list!
Note this post was edited. The Feature Suggestion List was removed so members will not be become confused where to locate it in this thread. The Feature Suggestion List will be the first 1st post 1st page in this thread always. Thanks.
Great news on September 11, 2008 a version of CD was released. This sounds like an upgrade to suggest for XLD.
Read the info below. Finally it seems like the drive cache problem may fixed!
cdparanoia 10.2 final released
10.2 is a substantial upgrade release over 10.1.
10.2 includes a raft of minor bugfixes in device scan, device autosense and the transport layer.
More importantly, 10.2 addresses serious CDROM drive cache modelling deficiencies that exist in earlier versions. In a nutshell, a sizable fraction of modern drives exhibit new and exciting readahead cache abuses/bugs of which older versions of cdparanoia were not fully aware. This means that skips and cracks could slip through the cache management strategy of older versions completely undetected. 10.2 fully addresses and models these new cache behaviors.
10.2 also includes a cache analysis option (-A) to do a slow and thorough offline check of the drive's cache behavior. The feature also dumps a detailed log to assist in debugging should either the test or cdparanoia's ripping go awry in any way. After all... better thoroughly safe than sorry.
10.2 also includes a cache analysis option (-A) to do a slow and thorough offline check of the drive's cache behavior. The feature also dumps a detailed log to assist in debugging should either the test or cdparanoia's ripping go awry in any way. After all... better thoroughly safe than sorry.
I wonder if the cache analysis option can be made to run on OS X? This would be a quite useful setup feature for XLD, to say the least.
I did just download the cdparanoia 10.2 src. I will see if the -A option will work from the command line.
I agree with Pepzhez and will add it to the suggested feature list.
These are two features I already talked with tmkk, and he already said will be implemented as soon as other more important ones are done. I'm only posting them here so that more people can keep track of them:
1. Add option to automatically save a M3U file, for the folks who need them.
2. Add option to "Always ask" in the Output Directory preferences...
These are two features I already talked with tmkk, and he already said will be implemented as soon as other more important ones are done. I'm only posting them here so that more people can keep track of them:
1. Add option to automatically save a M3U file, for the folks who need them.
2. Add option to "Always ask" in the Output Directory preferences...
Thanks MacMelo thats why this thread exists! I will be happy to update the list.
Just my general 2 cents: it was just a matter of time until an open source ripper came along that would most likely develop faster and more user-oriented than either one of the current two closed-source alternatives.
I still don't understand why Andre does not open his code - what's the point in keeping it locked and unchanged when he is not earning money with it anyways? XLD will surpass EAC eventually and hopefully gets ported to Windows soon.
Closed source in audio ripping won't last long. Transparency is key here, just like it is with audio codecs, which is why FLAC will always lead head-and-shoulders over closed-source attempts such as TAK... .
Let's hope Andre wakes up one of these days... .
ff
XLD will surpass EAC eventually and hopefully gets ported to Windows soon.
Not without pointer support, it won't.
EDIT: <Notices the following post has avoided this one>
It is *highly desirable* that XLD incorporate the (-A) option!
It would seem unnecessary (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=65873&view=findpost&p=588053).
Windows Ripping Brigade
Zealots wear blinders. It's particularly funny to see that they're not noticing the 800 pound gorilla in the room.
From the cdparanoia news page:
10.2 also includes a cache analysis option (-A) to do a slow and thorough offline check of the drive's cache behavior. The feature also dumps a detailed log to assist in debugging should either the test or cdparanoia's ripping go awry in any way. After all... better thoroughly safe than sorry.
It is *highly desirable* that XLD incorporate the (-A) option!
XLD will surpass EAC eventually and hopefully gets ported to Windows soon.
Correction:
XLD will surpass EAC in about six more minutes and hopefully never gets ported to Windows, because if it *did* get ported to Windows, how would I then be able to childishly revel in the Windows Ripping Brigade's bad karma that they brought upon themselves by spending the past decade penning snarly "Why don't you buy a Wintel machine/use Wine/use Parallels/buy a copy of Windows; why should André port his program to an inferior OS, anyway?!" responses every time some hapless, innocent individual asked "What is the Mac equivalent to EAC?"Just kidding.
(Sort of. )
Anyway Pepzhez, XLD is clearly a dead project as there hasn't been an update for at least 5 hours.
Anyway Pepzhez, XLD is clearly a dead project as there hasn't been an update for at least 5 hours.
5 hours!? Crap. Doom. Past few weeks for naught. Might as well mow the yard.
5 hours!? Crap. Doom. Past few weeks for naught. Might as well mow the yard.
Not with your overpriced, underpowered, single-button mower I hope.
5 hours!? Crap. Doom. Past few weeks for naught. Might as well mow the yard.
Not with your overpriced, underpowered, single-button mower I hope.
I wish! Gots this old cheapo that will not die. To be On Topic: XLD is making me hapy enough I do believe my Parallels setup's days are numbered.
Ability to switch between using both CD Paranoia II and III.
This will help everyone with comparison testing.
Edit - well that didn't take too long....
Ability to switch between using both CD Paranoia II and III.
This will help everyone with comparison testing.
Edit - well that didn't take too long....
I joked with tmkk that all I am doing is trying maintain and organize a suggested features list and I am having a difficult time keeping up with XLD feature changes. tmkk is truly a gifted developer to update the software so quickly!
The check file with accuraterip does not seem to work correctly with Apple Lossless... Any ideas?
The check file with accuraterip does not seem to work correctly with Apple Lossless... Any ideas?
Could you describe the problem, please?
The check file with accuraterip does not seem to work correctly with Apple Lossless... Any ideas?
Could you describe the problem, please?
I've ripped an album as a single file (Apple Lossless) + cue. The log tells me it was in the AR DB and that all the tracks were accurately ripped.
When I load this cue file up in XLD the "Check file with AccurateRip" function does not work as it should. That is, it instantly pops up a dialog box stating the album is NOT in the AR DB.
Now if I use XLD convert this file to a Single FLAC, AIFF, or WAV and cue file it works just great.
The following changes to log report:
- Indicate which version of CD Paranoia was used during ripping
- Place all of the AccurateRip results at the bottom of the log report instead of underneath each track listing similar to EAC. This would allow quick review of AccurateRip results!
- Indicate the setting of the "Strength of cache defeating ability" feature in the log report
I've ripped an album as a single file (Apple Lossless) + cue. The log tells me it was in the AR DB and that all the tracks were accurately ripped.
When I load this cue file up in XLD the "Check file with AccurateRip" function does not work as it should. That is, it instantly pops up a dialog box stating the album is NOT in the AR DB.
Now if I use XLD convert this file to a Single FLAC, AIFF, or WAV and cue file it works just great.
I don't use cue sheets, so obviously never noticed this problem. Please do let tmkk know about this.
I've ripped an album as a single file (Apple Lossless) + cue. The log tells me it was in the AR DB and that all the tracks were accurately ripped.
When I load this cue file up in XLD the "Check file with AccurateRip" function does not work as it should. That is, it instantly pops up a dialog box stating the album is NOT in the AR DB.
Now if I use XLD convert this file to a Single FLAC, AIFF, or WAV and cue file it works just great.
I don't use cue sheets, so obviously never noticed this problem. Please do let tmkk know about this.
How do I go about contacting him? I found an account on here by that name, but they have only made 1 post. Is that him?
How do I go about contacting him? I found an account on here by that name, but they have only made 1 post. Is that him?
App's webpage has an email link.
XLD Version 20080916 adds the following features and improvements. I will add the ones that were suggest by thread to the Addition of Suggestions and Development Explanations section of the list. The improvements just keep coming!
Supported simultaneous codec conversion
Select "Multiple Formats" in the output format and check the preferred format in the option. Note that WAV, AIFF, PCM and WAVE64 is exclusive each other.
XLD now recognizes '/' (slash) as a directory separator in the filename format field
XLD creates folder automatically. You can save files in the preferred folder by its title, artist, etc.
Supported album artist (%A) and format name (%f) in the filename field
Added option to disable embedding cue sheet in FLAC and WavPack encoder
Integrated drive caching ability measurement routine of CDParanoia III 10.2
To measure, open a CD and choose "Measure Drive Cache Ability" in File menu.
Improved sample length detection routine of Apple Lossless decoder
XLD Version 20080916 adds the following features and improvements. I will add the ones that were suggest by thread to the Addition of Suggestions and Development Explanations section of the list. The improvements just keep coming!
Supported simultaneous codec conversion
Select "Multiple Formats" in the output format and check the preferred format in the option. Note that WAV, AIFF, PCM and WAVE64 is exclusive each other.
XLD now recognizes '/' (slash) as a directory separator in the filename format field
XLD creates folder automatically. You can save files in the preferred folder by its title, artist, etc.
Supported album artist (%A) and format name (%f) in the filename field
Added option to disable embedding cue sheet in FLAC and WavPack encoder
Integrated drive caching ability measurement routine of CDParanoia III 10.2
To measure, open a CD and choose "Measure Drive Cache Ability" in File menu.
Improved sample length detection routine of Apple Lossless decoder
One word:
Holycrap!
There are a few outstanding issues regarding AR logging.
Here are some excerpts from this recent post:
http://www.hydrogenaudio.org/forums/index....st&p=588543 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=65873&view=findpost&p=588543)
X Lossless Decoder version 20080916 (91.0)
XLD extraction logfile from 2008-09-15 15:17:24 -0400
Various Artists / Whatever - The 90's Pop & Culture Box
Track 05
CRC32 hash : 77B4A906
AccurateRip signature : 664B49C6
->Rip may not be accurate.
Track 08
CRC32 hash : B6A08419
AccurateRip signature : 9286C262
->Rip may not be accurate.
Track 17
CRC32 hash : B72354FA
AccurateRip signature : 373933C8
->Rip may not be accurate.
X Lossless Decoder version 20080916 (91.0)
XLD extraction logfile from 2008-09-15 15:49:26 -0400
Various Artists / Whatever - The 90's Pop & Culture Box
Track 05
CRC32 hash : 4400BEBA
AccurateRip signature : 36D13166
->Accurately ripped! (confidence 6)
(matched with the different offset correction value;
calculated using an additional offset of 54)
Track 08
CRC32 hash : B6A08419
AccurateRip signature : 9286C262
->Accurately ripped! (confidence 6)
(matched with the different offset correction value;
calculated using an additional offset of 54)
Track 17
CRC32 hash : B72354FA
AccurateRip signature : 373933C8
->Accurately ripped! (confidence 6)
(matched with the different offset correction value;
calculated using an additional offset of 54)
These are two different rips of the same disc. With track 5 there are two different checksums, so it would make sense that one of the rips can be verified with AR while the other can't. On the other hand, tracks 8 and 17 appear to give identical results, though the AR reporting is not consistent.
Add the ability when using simultaneous codec conversion to choose the type of output for each format selected such as Include pregap, Exclude pregap or Save as a single file while having independent control of the Format of filename. An example would be to rip a CD with the 1st format as FLAC file selecting a single file +cue with Format of filename output as %A/%T/%f/%T. The 2nd format as an AAC file selecting to Include pregap with the Format of filename output as %A/%T/%f/%n %t. Both formats should have the ability to share common folders in Format of filename.
A Few New Requests:
- Give us an option to automatically not use CD Paranoia when there is an AccurateRip DB entry present. In other words it shoudl function how DBPA CD Ripper does... Rip in burst mode first, then if there is a mismatch switch over to secure ripping. Right now with my current drive I am seeing a rip speed of less than 2.0x
- Eliminiate the multiple windows. Having 3 windows open just to start ripping, edit metadata and monitor progress is rather annoying.
- Allow album art to be automatically saved to output folder as a jpg instead of being embedded in output file(s).
- Allow different naming schemes for single file vs multiple tracks.
Also, I don't have a cd on hand to test this with, but can XLD handle a pregap hidden track?
Also, I have emailed tmkk about the Apple Lossless + CUE bug(s)... He tried to fix one of them in today's release but it is not working for me.
A Few New Requests:- Give us an option to automatically not use CD Paranoia when there is an AccurateRip DB entry present. In other words it shoudl function how DBPA CD Ripper does... Rip in burst mode first, then if there is a mismatch switch over to secure ripping. Right now with my current drive I am seeing a rip speed of less than 2.0x
- Eliminiate the multiple windows. Having 3 windows open just to start ripping, edit metadata and monitor progress is rather annoying.
- Allow album art to be automatically saved to output folder as a jpg instead of being embedded in output file(s).
- Allow different naming schemes for single file vs multiple tracks.
Also, I don't have a cd on hand to test this with, but can XLD handle a pregap hidden track?
Also, I have emailed tmkk about the Apple Lossless + CUE bug(s)... He tried to fix one of them in today's release but it is not working for me.
I added your feature suggestions to the list. I did not place you suggestion to allow different naming schemes for single file vs multiple tracks because I believe that suggestion is the same as the posted number 65 above. If have misunderstood your suggestion and it is not the same as post number 65 I place it in the list. Thank for your input nice ideas.
It's so wonderful to see development of this app progress. As far as feature requests, I would love to be able to convert whole folders and nested subfolders of audio files. Currently, you have to drop the audio files themselves on the application.
Also, since the option exists to have XLD add the file to the itunes library, there's no need to have a 2nd copy of the file. This occurs when itunes copies the file when adding to its library and then the file created by XLD is left over. It would be nice to have an option to automatically delete the second copy of the file that XLD creates if you have itunes set to copy files into the library. In other words, move the files to the itunes library instead of copying them.
Thanks for considering!
Regards!
EDIT: clarified my explanation of deleting files
It's so wonderful to see development of this app progress. As far as feature requests, I would love to be able to convert whole folders and nested subfolders of audio files. Currently, you have to drop the audio files themselves on the application.
Also, since the option exists to have XLD add the file to the itunes library, there's no need to have a 2nd copy of the file. This occurs when itunes copies the file when adding to its library and then the file created by XLD is left over. It would be nice to have an option to automatically delete the second copy of the file that XLD creates if you have itunes set to copy files into the library.
Thanks for considering!
Regards!
G-Force I added your feature suggestions to the feature suggestion list at the beginning of this thread. I f look you at the bottom of the first post of this thread you find all the new suggestions waiting for a reply from the developer on the feasibility of adding to XLD. Thanks
Yes. Something is wrong with XLD's automatic AccurateRip check.
Here is a rip at the correct drive offset of 48:
X Lossless Decoder version 20080916b (91.2)
XLD extraction logfile from 2008-09-16 05:45:58 -0500
CAN / Ege Bamyasi
Used drive : PIONEER DVD-RW DVR-108 (revision 1.17)
Use cdparanoia mode : YES (CDParanoia III 10.2 engine)
Disable audio cache : YES (1/14)
Read offset correction : 48
Max retry count : 100
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:32 | 09:29:38 | 32 | 42744
2 | 09:29:70 | 04:47:37 | 42745 | 64306
3 | 14:17:32 | 05:35:50 | 64307 | 89481
4 | 19:53:07 | 03:32:13 | 89482 | 105394
5 | 23:25:20 | 10:31:62 | 105395 | 152781
6 | 33:57:07 | 03:05:38 | 152782 | 166694
7 | 37:02:45 | 03:04:25 | 166695 | 180519
List of suggested offset correction values
# | Absolute | Relative | Confidence
------------------------------------------
1 | -100 | -148 | 7
Track 02
Filename : /Test 6/02 - Sing Swan Song.wav
CRC32 hash : 32D7B7E7
CRC32 hash (skip zero) : 3B74814B
AccurateRip signature : 4F050E3A
->Accurately ripped! (confidence 15)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 03
Filename : /Test 6/03 - One More Night.wav
CRC32 hash : 34A884D2
CRC32 hash (skip zero) : C5E3B2DF
AccurateRip signature : 8CFAAF7B
->Accurately ripped! (confidence 16)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
No errors occurred
End of status report
Here I changed the drive offset to 49 and re-ripped, to see if the AccurateRip check feature is working:
X Lossless Decoder version 20080916b (91.2)
XLD extraction logfile from 2008-09-16 05:48:32 -0500
CAN / Ege Bamyasi
Used drive : PIONEER DVD-RW DVR-108 (revision 1.17)
Use cdparanoia mode : YES (CDParanoia III 10.2 engine)
Disable audio cache : YES (1/14)
Read offset correction : 49
Max retry count : 100
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:32 | 09:29:38 | 32 | 42744
2 | 09:29:70 | 04:47:37 | 42745 | 64306
3 | 14:17:32 | 05:35:50 | 64307 | 89481
4 | 19:53:07 | 03:32:13 | 89482 | 105394
5 | 23:25:20 | 10:31:62 | 105395 | 152781
6 | 33:57:07 | 03:05:38 | 152782 | 166694
7 | 37:02:45 | 03:04:25 | 166695 | 180519
List of suggested offset correction values
# | Absolute | Relative | Confidence
------------------------------------------
1 | 48 | -1 | 16
2 | -100 | -149 | 7
Track 02
Filename : /Test 5/02 - Sing Swan Song.wav
CRC32 hash : CEAE0E0C
CRC32 hash (skip zero) : 77CD99FF
AccurateRip signature : 7AB73CDF
->Accurately ripped! (confidence 15)
(matched with the different offset correction value;
calculated using an additional offset of -1)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 03
Filename : /Test 5/03 - One More Night.wav
CRC32 hash : 06E2DC29
CRC32 hash (skip zero) : 79098D2F
AccurateRip signature : 5D7A2D6E
->Accurately ripped! (confidence 16)
(matched with the different offset correction value;
calculated using an additional offset of -1)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
No errors occurred
End of status report
The CRCs are different because the tracks were ripped using different offsets. This part is correct.
Here's the problem: the second log says that the tracks "matched with the different offset correction value; calculated using an additional offset of -1." This seems correct, but the AccurateRip signatures in the second log are completely different from the ones in the first log. They should be the same.
What causes the different AccurateRip signatures in the second log? This makes no sense.
First log:
Track 02 - AccurateRip signature : 4F050E3A
Track 03 - AccurateRip signature : 8CFAAF7B
Second log:
Track 02 - AccurateRip signature : 7AB73CDF
Track 03 - AccurateRip signature : 5D7A2D6E
G-Force I added your feature suggestions to the feature suggestion list at the beginning of this thread. I f look you at the bottom of the first post of this thread you find all the new suggestions waiting for a reply from the developer on the feasibility of adding to XLD. Thanks
Thanks for adding my requests. Along the same lines as my first suggestion, it would also be nice to be able to drag files from itunes to XLD to start the encoding process.
Regards,
Would anybody be willing to work with me on a UI mockup? I have some ideas I've been playing aroudn with but I'd like some input from others, too.
hello, can anyone please tell me if xld re-encodes mp3 files splitted from a big mp3+cue set?
are they 'losslessly' split or are they re-encoded??
couldn't find the answer anywhere, thanks in advance.
hello, can anyone please tell me if xld re-encodes mp3 files splitted from a big mp3+cue set?
are they 'losslessly' split or are they re-encoded??
couldn't find the answer anywhere, thanks in advance.
If you have compliant cue sheet that is correctly associated with the MP3 file XLD will allow you to convert it into another format.
are they 'losslessly' split or are they re-encoded??
No. Unless you convert the file you want to split into a lossless format. Be advised you will never be able to reconstruct the original MP3 that has been encoded but if you choose a lossless format it will preserve what you have left of the original MP3 you wish split thus being closer to the source file.
This is going way off-topic, but yes it is possible to losslessly split an mp3 file without re-encoding. You're likely going to break the bit reservoir, but it works. Provided you don't modify the split tracks in a way that the changes cannot be perfectly undone, they can be recombined giving back the original mp3 file.
This is going way off-topic, but yes it is possible to losslessly split an mp3 file without re-encoding. You're likely going to break the bit reservoir, but it works. Provided you don't modify the split tracks in a way that the changes cannot be perfectly undone, they can be recombined giving back the original mp3 file.
There was and maybe still is a freeware OS X app called AudioSlicer that did split mp3s losslessly. I don't think it could handle cue sheets, though.
There was and maybe still is a freeware OS X app called AudioSlicer that did split mp3s losslessly. I don't think it could handle cue sheets, though.
SebastianG wrote a tool called pcutmp3 which can also do this- http://www.hydrogenaudio.org/forums/index....showtopic=35654 (http://www.hydrogenaudio.org/forums/index.php?showtopic=35654) (but the download link is dead).
In the "lossless split" issue, my favorite Mac app is Fission (http://www.rogueamoeba.com/fission/)... Not free, though...
It handles cue sheets beautifully!
hello, can anyone please tell me if xld re-encodes mp3 files splitted from a big mp3+cue set?
are they 'losslessly' split or are they re-encoded??
couldn't find the answer anywhere, thanks in advance.
If you have compliant cue sheet that is correctly associated with the MP3 file XLD will allow you to convert it into another format.
are they 'losslessly' split or are they re-encoded??
No. Unless you convert the file you want to split into a lossless format. Be advised you will never be able to reconstruct the original MP3 that has been encoded but if you choose a lossless format it will preserve what you have left of the original MP3 you wish split thus being closer to the source file.
neovibe asked for a for a lossless solution using
XLD. The key word here is re-encodes. I gave a solution using XLD's current capabilities as asked. The solutions that everybody has given neovibe are great and simply rewrites the file with out re-encoding(transcoding,converting) the MP3file. These applications split(slices) the existing MP3 file into several segments which then become individual tracks with no changes to audio signal other than splits including the new metadata. These applications mentioned simple automates the process. I think this should be a feature to eventually be incorporated into XLD if any of these applications source is available for use. tmkk stated XLD is an audio converter and we the users have placed the emphasis on the ripping portion of XLD here of late.
All of these extra features are nice, but I really think the ripper itself ought to be the first priority.
For instance, why does XLD produce inconsistent results when "disable cache" is unchecked with drives that don't cache with cdparanoia 10.2? Of course I'm aware that XLD was designed before 10.2 was released, but it does seem strange that, according to tmkk, the only reliable way to get consistent results with a non-caching drive is to check "disable cache" and set the strength to minimum.
I just wonder what causes the ripper to behave like that with cdparanoia 10.2.
All of these extra features are nice, but I really think the ripper itself ought to be the first priority.
For instance, why does XLD produce inconsistent results when "disable cache" is unchecked with drives that don't cache with cdparanoia 10.2? Of course I'm aware that XLD was designed before 10.2 was released, but it does seem strange that, according to tmkk, the only reliable way to get consistent results with a non-caching drive is to check "disable cache" and set the strength to minimum.
I just wonder what causes the ripper to behave like that with cdparanoia 10.2.
I agree with you Pepzhez. I think the ripper should be refined to a sharpened laser point of DAE perfection. Without an accurate and reliable ripper what is the point of converting the extracted audio files. My only concern is that tmkk does not burn out from not following his original purpose in creating XLD.
I think first we have to find out if the CD Paranoia version III 10.2 is reacting in similar manner on Linux machines. That would help us to determine if the problem lies in the new CD Paranoia III 10.2 library or if it has some type of conflict with some of the XLD code. I hope these issues can be solved because they create doubt about the accuracy of rips created on a Mac. Let me know if there any trouble shooting or testing that I can do to help.
For instance, why does XLD produce inconsistent results when "disable cache" is unchecked with drives that don't cache with cdparanoia 10.2? Of course I'm aware that XLD was designed before 10.2 was released, but it does seem strange that, according to tmkk, the only reliable way to get consistent results with a non-caching drive is to check "disable cache" and set the strength to minimum.
And apparently, most drives are considered non-caching by cdparanoia.
I'll try just keeping the cache disabling on with the weak setting.
It might be good to just eliminate the the cache checkbox until this changes.
Edit - I take back the eliminate the checkbox thing. It might just needlessly slow down the "old cdparanoia" setting. Perhaps just a warning for those who might not have seen the above post?
I think first we have to find out if the CD Paranoia version III 10.2 is reacting in similar manner on Linux machines. That would help us to determine if the problem lies in the new CD Paranoia III 10.2 library or if it has some type of conflict with some of the XLD code. I hope these issues can be solved because they create doubt about the accuracy of rips created on a Mac. Let me know if there any trouble shooting or testing that I can do to help.
Cdparanoia shouldn't behave any differently whether it is running on OS X or Linux or Windows. That's the whole point of it: it is platform independent. Most drives did not cache with cdparanoia 9.8, so they definitely won't cache with 10.2.
The entire "disable cache" thing is a proprietary XLD invention that has nothing to do with cdparanoia -- and no one knows what it's actually doing.
Has anyone here managed to successfully compile cdparanoia 10.2 on OS X? I have no idea how the hell tmkk managed to do it.
I think first we have to find out if the CD Paranoia version III 10.2 is reacting in similar manner on Linux machines. That would help us to determine if the problem lies in the new CD Paranoia III 10.2 library or if it has some type of conflict with some of the XLD code. I hope these issues can be solved because they create doubt about the accuracy of rips created on a Mac. Let me know if there any trouble shooting or testing that I can do to help.
Cdparanoia shouldn't behave any differently whether it is running on OS X or Linux or Windows. That's the whole point of it: it is platform independent. Most drives did not cache with cdparanoia 9.8, so they definitely won't cache with 10.2.
The entire "disable cache" thing is a proprietary XLD invention that has nothing to do with cdparanoia -- and no one knows what it's actually doing.
Has anyone here managed to successfully compile cdparanoia 10.2 on OS X? I have no idea how the hell tmkk managed to do it.
I misunderstood that the disable cache feature was incorporated into CD Paranoia III 10.2. After reviewing the CD Paranoia web page it appears that solution to cache problem was just written into the release without it being an available option for the user(auto correction). So with that said would it possible for tmkk to remove the disable cache just for the new version of CD Paranoia? It seems like his implementation of the disable cache feature is not necessary with new version of CD Paranoia. Do know you of any reason to leave the old the version in XLD? .
So with that said would it possible for tmkk to remove the disable cache just for the new version of CD Paranoia? It seems like his implementation of the disable cache feature is not necessary with new version of CD Paranoia. Do know you of any reason to leave the old the version in XLD? .
I'm not at all sure what the principle behind the XLD disable cache feature even is. And I don't know how or why XLD behaves differently when it is switched on or off.
tmkk is the only one who knows if there's a reason to leave it there.
So with that said would it possible for tmkk to remove the disable cache just for the new version of CD Paranoia? It seems like his implementation of the disable cache feature is not necessary with new version of CD Paranoia. Do know you of any reason to leave the old the version in XLD? .
I'm not at all sure what the principle behind the XLD disable cache feature even is. And I don't know how or why XLD behaves differently when it is switched on or off.
tmkk is the only one who knows if there's a reason to leave it there.
Bonk was just released with CD Paranoia III 10.2. I wonder if it would worth downloading and running it through VMWare Fusion and XP to see if any differences exist between the XLD rips and the Bonk rips?
Here are some excerpts from this recent post:
http://www.hydrogenaudio.org/forums/index....st&p=588543 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=65873&view=findpost&p=588543)
X Lossless Decoder version 20080916 (91.0)
XLD extraction logfile from 2008-09-15 15:17:24 -0400
Various Artists / Whatever - The 90's Pop & Culture Box
Track 05
CRC32 hash : 77B4A906
AccurateRip signature : 664B49C6
->Rip may not be accurate.
Track 08
CRC32 hash : B6A08419
AccurateRip signature : 9286C262
->Rip may not be accurate.
Track 17
CRC32 hash : B72354FA
AccurateRip signature : 373933C8
->Rip may not be accurate.
X Lossless Decoder version 20080916 (91.0)
XLD extraction logfile from 2008-09-15 15:49:26 -0400
Various Artists / Whatever - The 90's Pop & Culture Box
Track 05
CRC32 hash : 4400BEBA
AccurateRip signature : 36D13166
->Accurately ripped! (confidence 6)
(matched with the different offset correction value;
calculated using an additional offset of 54)
Track 08
CRC32 hash : B6A08419
AccurateRip signature : 9286C262
->Accurately ripped! (confidence 6)
(matched with the different offset correction value;
calculated using an additional offset of 54)
Track 17
CRC32 hash : B72354FA
AccurateRip signature : 373933C8
->Accurately ripped! (confidence 6)
(matched with the different offset correction value;
calculated using an additional offset of 54)
These are two different rips of the same disc. With track 5 there are two different checksums, so it would make sense that one of the rips can be verified with AR while the other can't. On the other hand, tracks 8 and 17 appear to give identical results, though the AR reporting is not consistent.
Here's another try at this disk
X Lossless Decoder version 20080916c (91.3)
XLD extraction logfile from 2008-09-17 08:10:53 -0400
Various Artists / Whatever - The 90's Pop & Culture Box
Used drive : MATSHITA DVD-R UJ-857E (revision ZF1E)
Use cdparanoia mode : YES (CDParanoia III 10.2 engine)
Disable audio cache : YES (1/14)
Read offset correction : 754
Max retry count : 100
Track 08
Filename : /Users/davesprou/Desktop/XLD Rips/08 Various Artists - Brian Wilson.aiff
CRC32 hash : D96957AC
CRC32 hash (skip zero) : C55E478F
AccurateRip signature : 3420B1C6
->Rip may not be accurate.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 1
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 1
Duplicated bytes error (maybe fixed) : 1
Inconsistency in error sectors : 0
Track 8 being the only problem.
I also just got another problem AR free rip with CDParanoia mode not enabled.
The enabling cache thing doesn't quite cure things in this case.
Don't worry, guys. I've been talking with tmkk and a solution is on the way.
There is no problem with XLD. It is just that the sector read ahead default (150 sectors) was made with the old cdparanoia in mind. Cdparanoia 10.2 has a much higher cache tolerance.
There is nothing wrong with XLD. Cdparanoia 10.2 requires a bit of rethinking about the default values, that's all. This can be done. Sit tight.
Quite honestly, 10.2 eliminates the need to even discuss caching issues and cache disabling. Programs need to reflect this.
Question for you XLD users:
Do any of you bother to use the old cdparanoia engine?
If the old cdparanoia engine were to be taken out of XLD, would you miss it?
In other words, if XLD concentrated on being exclusively a cdparanoia 10.2 ripper, would you like that idea?
I actually think it would be better to get rid of the old cdparanoia engine.
@Knucklehead: Are you certain that 48 is the correct offset for your drive? I believe that the correct offset for your Matshita is 102.
Question for you XLD users:
Do any of you bother to use the old cdparanoia engine?
If the old cdparanoia engine were to be taken out of XLD, would you miss it?
In other words, if XLD concentrated on being exclusively a cdparanoia 10.2 ripper, would you like that idea?
I actually think it would be better to get rid of the old cdparanoia engine.
I agree with that statement it adds to much confusion. This was a major update for CD Paranoia and with cache handling improvements I don't see a need for the old engine provided that the new engine can be incorporated into XLD without any problems.
Track 8 being the only problem.
I also just got another problem AR free rip with CDParanoia mode not enabled.
The enabling cache thing doesn't quite cure things in this case.
I posted your log results for a different reason than caching/CDParanoia. They indicate a clear problem with AR reporting. Two tracks are exactly the same based on the CRCs and AR signatures, yet there are two different AR results.
Track 8 being the only problem.
I also just got another problem AR free rip with CDParanoia mode not enabled.
The enabling cache thing doesn't quite cure things in this case.
I posted your log results for a different reason than caching/CDParanoia. They indicate a clear problem with AR reporting. Two tracks are exactly the same based on the CRCs and AR signatures, yet there are two different AR results.
There was also track 5, which had an actual rip problem. I didn't realize at the time about the AR problem.
The track shows two different problems, and can be used for either purpose ---- or am I missing something else?
Question for you XLD users:
Do any of you bother to use the old cdparanoia engine?
If the old cdparanoia engine were to be taken out of XLD, would you miss it?
In other words, if XLD concentrated on being exclusively a cdparanoia 10.2 ripper, would you like that idea?
I actually think it would be better to get rid of the old cdparanoia engine.
@Knucklehead: Are you certain that 48 is the correct offset for your drive? I believe that the correct offset for your Matshita is 102.
But how would I rip my CD with a hole in it?
Leave it for now until we know 10.2 is working properly. I don't think the old version is getting in the way of anything.
I'll go back and try things again tonight with the proper offset values to be sure if that's a factor in my results.
There is a legitimate reason why I asked this question. The old version is actually getting in the way of things, and it would make it far easier to optimize XLD for 10.2 if the old engine were removed altogether.
On top of that, I don't know why anyone wants two engines in a ripper. Particularly when one of them is an older, obsolete version of the other.
On top of that, I don't know why anyone wants two engines in a ripper. Particularly when one of them is an older, obsolete version of the other.
Agreed... Some may say that it's nice to give users the option to choose A or B... But if A is clearly superior than B, it's the only logical choice... Keeping B as an option only complicates things, without adding anything...
Why would anyone prefer that?
There is a legitimate reason why I asked this question. The old version is actually getting in the way of things, and it would make it far easier to optimize XLD for 10.2 if the old engine were removed altogether.
On top of that, I don't know why anyone wants two engines in a ripper. Particularly when one of them is an older, obsolete version of the other.
By all means - Take it out if it's getting in the way of development.
I can keep an keep a copy of the current version with the old ripper and disable the update feature.
I have about a dozen toolboxes filled with tools. Every time I get a new tool (which is pretty much all the time)
I don't throw my old tools out. There's a function for every one of them.
Previous versions of XLD didn't, but would it be possible to copy over ALL tags when transcoding from one format to another? Even non-standard ones?
...Or at least the tags that iTunes can/will append to files it recognises (e.g. ALBUMSORTORDER, ITUNESCOMPILATION, etc.)
On top of that, I don't know why anyone wants two engines in a ripper. Particularly when one of them is an older, obsolete version of the other.
Agreed... Some may say that it's nice to give users the option to choose A or B... But if A is clearly superior than B, it's the only logical choice... Keeping B as an option only complicates things, without adding anything...
Why would anyone prefer that?
Is the new ripper clearly superior in all cases?
Where has that been proven?
Is the new ripper clearly superior in all cases?
Where has that been proven?
1. Wait for the next XLD update.
2. Monty clearly feels that cdparanoia 10.2 is superior to 10.1.
Is the new ripper clearly superior in all cases?
Where has that been proven?
1. Wait for the next XLD update.
2. Monty clearly feels that cdparanoia 10.2 is superior to 10.1.
I'll take his word for it.
I’ve come across some problems in my latest test, but like I said before --- so what!
I'll just bag it till the next update.
As the world teeters around us ..... this is good.
Whatever problems you are having in your latest tests have nothing to do with cdparanoia 10.2 itself. XLD can and will be optimized to use 10.2 most efficiently.
Previous versions of XLD didn't, but would it be possible to copy over ALL tags when transcoding from one format to another? Even non-standard ones?
...Or at least the tags that iTunes can/will append to files it recognises (e.g. ALBUMSORTORDER, ITUNESCOMPILATION, etc.)
ozmosis82 I added your suggestion to the suggested features list which located in the 1st post of this thread. Thank you for your suggestion.
I'll join the chorus of people hoping for 10.1 to be removed. It just seems to add confusion with no tangible benefits.
I'll join the chorus of people hoping for 10.1 to be removed. It just seems to add confusion with no tangible benefits.
I suggested to tmkk that if he was worried about removing the old CD Paranoia III 10.1 engine and how it would effect XLD's current user base, that he could place an older version of XLD that did not contain the new CD Paranoia III 10.2 engine on Rarewares appeasing the small portion of the users that might be interested in having access to the old CD Paranoia III 10.1 engine.
ozmosis82 I added your suggestion to the suggested features list which located in the 1st post of this thread. Thank you for your suggestion.
Thank YOU for taking it into consideration!
Another suggestion would be to have XLD remember the metadata that is entered for a CD (either manually, or when obtained from freedb), so that users don't have to re-enter the information if they insert the disc again.
...VERY frustrating when XLD hangs on a track (due to a scratch or what-have-you) and no amount of clicking on the "Cancel" button stops the ripping process, because I then have to quit and restart XLD... AND re-enter all my metadata.
EDIT:
Oh! And %y for Year, %g for Genre, and %something for Disc Number when specifying an output filename format!
New of version of XLD.
Version 20080919:
* Removed all options regarding cache
* Now the default setting is the "strongest" one in the previous version (the same as cdparanoia 10.2 default). I'll remove the old engine if there is no problem with this version. Integrated drive offset database into application
You can select the offset correction value for your drive if it is registered in the database.
Hopefully this will resolve the problem inaccurate rips some that some users have experienced.
I've been testing it. Very fast, very consistent.
A good one button "cancel" option that will get out of the endless hang situation, Also just to easily cancel a rip you just started with some wrong settings.
My external drive also disappears in the hang situations, and needs to be disconnected or restarted to show up again - if that can be fixed.
The auto-offset function is great. Only seems to recognize my internal drive though. External drives are pretty important for good ripping with Macs.
Is this version the one with the talked about better integration of 10.2, or just an intermediate step?
In the release notes: Now the default setting is the "strongest" one in the previous version (the same as cdparanoia 10.2 default). I'll remove the old engine if there is no problem with this version.
CD Paranoia 10.2 read ahead value is set to a default 550 sectors while 10.1 default read ahead value is set 150 sectors.
Moderation: Removed quote from previous post, what's the point??? Removed TOS #9 Reference!
It's a much better integration of 10.2, yes it is. Much faster 10.2 ripping speed too. Try it out. There's nothing intermediary about it. It's quite impressive.
Several people have have been confused by the use of the word "suggested" in the AR offset correction value list:
List of suggested offset correction values
# | Absolute | Relative | Confidence
------------------------------------------
1 | 919 | 871 | 10
That is confusing many people into believing that AR is "suggesting" that changes are required. Several people have written to me asking me why the log is "suggesting" they change the offsets.
I think it would be much less confusing (and much more accurate) if the log were reworded to read as 'List of
alternate offset correction values'.
@ pepzhez Added your suggestion to the list
@ knucklehead Added your suggestions. The external drives are being recognized on my system (firewire400 boxes).
(the same as cdparanoia 10.2 default). I'll remove the old engine if there is no problem with this version.
CD Paranoia 10.2 read ahead value is set to a default 550 sectors while 10.1 default read ahead value is set 150 sectors. This was not adequate for 10.2 according kjoerup posted at Pedro's forum.
XLD/cdparanoia 10.2 is actually now set at a read ahead default of 1200. Your drive would have to cache more than 1200 sectors (more than 2750KB) worth of audio in order to begin experiencing potential caching problems. It's highly improbable there is such a drive in the market today.
Has anyone ever seen a drive that caches anywhere near that much audio? I think the biggest audio cache I've ever tested was about 1100KB.
This is the largest drive audio cache I have:
X Lossless Decoder version 20080919 (92.0)
XLD drive cache analysis logfile
Used drive : PIONEER DVD-RW DVR-108 (revision 1.17)
Your drive seems to have a cache of 139 sectors (319 Kbytes).
The cache size is small enough for cdparanoia III 10.2 engine.
End of status report
I believe that a default is fine. But a range feature should be available for people who's drives that do not cache or have extremely small caches to increase the speed of the ripping process for these users.
Moderation: Quote blown away, just say NO to screed.
@ knucklehead Thanks!
XLD drive offset detection also recognizes all 3 of my external Firewire 400 drives. I've had no problems with that at all.
I believe that a default is fine. But a range feature should be available for people who's drives that do not cache or have extremely small caches to increase the speed of the ripping process for these users.
And what is a drive that "does not cache"?
The "default" is the cdparanoia 10.2 spec. It was designed that way precisely so the user doesn't have to worry about cache anymore. 10.2 takes care of that on its own. You are still thinking of the way pre-10.2 cdparanoia and EAC work. 10.2 isn't like that. Unless some extraordinary super-sized audio cache is invented and marketed, 10.2 has effectively rendered the caching problem moot. There's nothing to adjust; a range feature would be useless -- and throttling cdparanoia isn't going to result in any speed gains. (But may result in other unforeseen problems.) Monty knew what he was doing when he designed 10.2. Trust it.
There's a thread on this here:
http://www.hydrogenaudio.org/forums/index....showtopic=65914 (http://www.hydrogenaudio.org/forums/index.php?showtopic=65914)
You are still thinking of the way pre-10.2 cdparanoia and EAC work.
Not to bust your chops, but just how does EAC work???
Drives that do not cache do not need flushing. Which drives don't cache? Well, NEC makes a few...
http://www.daefeatures.co.uk/search.php (http://www.daefeatures.co.uk/search.php)
Feel free to bust my chops. I don't mind!
There's caching and then there's "caching." No, I am not being fatuous.
What I meant is that the "caching" or "non-caching" status of a drive is a relative concept here, and said status is dependent upon, nay, defined by the internal standards of the ripping program being used. For EAC's purposes, a drive that caches more than 64KB of audio is, in practical terms, a "caching" drive. For cdparanoia 9.8, a drive that caches under 300KB can pragmatically be considered to be "non-caching." And we can be talking about the very same drive. Let's say this hypothetical drive caches 120KB. So, is it a caching drive, then? Technically speaking, of course it is. It caches 120KB. Will the aforementioned programs both treat it as a "caching" drive? Not necessarily.
What I was getting at (and admittedly did not articulate well at all) was that it's not useful to apply one program's set of standards to another's. The 10.2 drive cache tolerances are quite different from the old cdparanoia standards, and that forces a rethink in how we need to look at this.
My main point, however, was that it wouldn't be constructive or beneficial to throttle the 10.2 read ahead value down to zero for, say, a truly non-caching NEC drive. Certainly throttling 10.2 down to the old cdparanoia 150 sector read ahead default value didn't work well at all. I imagine that the results would be even worse if you attempted to take it all the way down. And even if that did work, what would be gained from it? I don't think you'd see a significant ripping speed increase.
Drives that do not cache do not need flushing. Which drives don't cache? Well, NEC makes a few...
http://www.daefeatures.co.uk/search.php (http://www.daefeatures.co.uk/search.php)
LG makes some too. I once bought the, pretty pricey at the time GSA-H10A, to try to get around the caching issue. Glad I was able to return it.
I'm also getting reacquainted with my NEC that I bought for the same reason. It's been sitting unused on a shelf for a couple of years for a good reason.
All my drives are showing up now with cache setting. Second program start did the trick.
Here's the latest results from the same old CD with my internal MacBook drive:
X Lossless Decoder version 20080919 (92.0)
XLD extraction logfile from 2008-09-19 07:39:49 -0400
Various Artists / Whatever - The 90's Pop & Culture Box
Used drive : MATSHITA DVD-R UJ-857E (revision ZF1E)
Use cdparanoia mode : NO
Disable audio cache : NO
Read offset correction : 102
Max retry count : 100
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:00 | 04:49:58 | 0 | 21732
2 | 04:49:58 | 03:15:57 | 21733 | 36414
3 | 08:05:40 | 03:41:13 | 36415 | 53002
4 | 11:46:53 | 03:15:55 | 53003 | 67682
5 | 15:02:33 | 02:47:24 | 67683 | 80231
6 | 17:49:57 | 04:12:69 | 80232 | 99200
7 | 22:02:51 | 04:28:32 | 99201 | 119332
8 | 26:31:08 | 04:46:14 | 119333 | 140796
9 | 31:17:22 | 04:33:28 | 140797 | 161299
10 | 35:50:50 | 02:53:26 | 161300 | 174300
11 | 38:44:01 | 03:25:15 | 174301 | 189690
12 | 42:09:16 | 03:58:16 | 189691 | 207556
13 | 46:07:32 | 04:06:47 | 207557 | 226053
14 | 50:14:04 | 05:28:58 | 226054 | 250711
15 | 55:42:62 | 03:33:44 | 250712 | 266730
16 | 59:16:31 | 03:27:29 | 266731 | 282284
17 | 62:43:60 | 03:59:04 | 282285 | 300213
18 | 66:42:64 | 05:03:44 | 300214 | 322982
19 | 71:46:33 | 04:13:20 | 322983 | 341977
Track 01
Filename : /Users/davesprou/Desktop/XLD Rips/01 Various Artists - Itszoweezee (Hot).aiff
CRC32 hash : 087BD8BB
CRC32 hash (skip zero) : FA76B8BF
AccurateRip signature : C15FBCD3
->Accurately ripped! (confidence 6)
Track 02
Filename : /Users/davesprou/Desktop/XLD Rips/02 Various Artists - Lovefool.aiff
CRC32 hash : 90151067
CRC32 hash (skip zero) : 1204805B
AccurateRip signature : 8C2B7F59
->Accurately ripped! (confidence 6)
Track 03
Filename : /Users/davesprou/Desktop/XLD Rips/03 Various Artists - Radiation Vibe.aiff
CRC32 hash : 56C16210
CRC32 hash (skip zero) : A7C7E4B3
AccurateRip signature : BF564A24
->Accurately ripped! (confidence 6)
Track 04
Filename : /Users/davesprou/Desktop/XLD Rips/04 Various Artists - The Impression That I Get.aiff
CRC32 hash : E0EC6FE4
CRC32 hash (skip zero) : 974BC3E6
AccurateRip signature : F4B69C7A
->Accurately ripped! (confidence 6)
Track 05
Filename : /Users/davesprou/Desktop/XLD Rips/05 Various Artists - Turn It On.aiff
CRC32 hash : 37E53DFA
CRC32 hash (skip zero) : A676F301
AccurateRip signature : AE8C1418
->Accurately ripped! (confidence 6)
Track 06
Filename : /Users/davesprou/Desktop/XLD Rips/06 Various Artists - Bitch.aiff
CRC32 hash : 05578D78
CRC32 hash (skip zero) : E1E54103
AccurateRip signature : BF5D2BA1
->Accurately ripped! (confidence 6)
Track 07
Filename : /Users/davesprou/Desktop/XLD Rips/07 Various Artists - Mmmbop.aiff
CRC32 hash : 9AC743E9
CRC32 hash (skip zero) : 308E095C
AccurateRip signature : 3A11D53F
->Accurately ripped! (confidence 6)
Track 08
Filename : /Users/davesprou/Desktop/XLD Rips/08 Various Artists - Brian Wilson.aiff
CRC32 hash : D1CD598B
CRC32 hash (skip zero) : D30C1AE1
AccurateRip signature : 9BD0321B
->Accurately ripped! (confidence 6)
Track 09
Filename : /Users/davesprou/Desktop/XLD Rips/09 Various Artists - Brick.aiff
CRC32 hash : BE2F2433
CRC32 hash (skip zero) : 2019BBDD
AccurateRip signature : 98F7CE24
->Accurately ripped! (confidence 6)
Track 10
Filename : /Users/davesprou/Desktop/XLD Rips/10 Various Artists - Sex And Candy.aiff
CRC32 hash : 401307F6
CRC32 hash (skip zero) : 4C630465
AccurateRip signature : 96EB8354
->Accurately ripped! (confidence 6)
Track 11
Filename : /Users/davesprou/Desktop/XLD Rips/11 Various Artists - Walkin' On The Sun.aiff
CRC32 hash : 4707A2A7
CRC32 hash (skip zero) : 26C12E7C
AccurateRip signature : 565A01E8
->Accurately ripped! (confidence 6)
Track 12
Filename : /Users/davesprou/Desktop/XLD Rips/12 Various Artists - Tubthumping.aiff
CRC32 hash : D5E6DA12
CRC32 hash (skip zero) : 31E49FF7
AccurateRip signature : 60F72F09
->Accurately ripped! (confidence 6)
Track 13
Filename : /Users/davesprou/Desktop/XLD Rips/13 Various Artists - 6 Underground.aiff
CRC32 hash : 2F9465D1
CRC32 hash (skip zero) : E62270C8
AccurateRip signature : 80C5AC0D
->Accurately ripped! (confidence 6)
Track 14
Filename : /Users/davesprou/Desktop/XLD Rips/14 Various Artists - Lullaby.aiff
CRC32 hash : E30E9347
CRC32 hash (skip zero) : 390CD1EB
AccurateRip signature : 70F81279
->Accurately ripped! (confidence 6)
Track 15
Filename : /Users/davesprou/Desktop/XLD Rips/15 Various Artists - Slide.aiff
CRC32 hash : 7CB776B1
CRC32 hash (skip zero) : 7061D271
AccurateRip signature : D4E83B19
->Accurately ripped! (confidence 6)
Track 16
Filename : /Users/davesprou/Desktop/XLD Rips/16 Various Artists - Kiss Me.aiff
CRC32 hash : 85D8468C
CRC32 hash (skip zero) : 75B48000
AccurateRip signature : B4F5D28D
->Accurately ripped! (confidence 6)
Track 17
Filename : /Users/davesprou/Desktop/XLD Rips/17 Various Artists - Steal My Sunshine.aiff
CRC32 hash : 1BAE6EF2
CRC32 hash (skip zero) : 67624197
AccurateRip signature : 4E9BBBD2
->Accurately ripped! (confidence 6)
Track 18
Filename : /Users/davesprou/Desktop/XLD Rips/18 Various Artists - What It's Like.aiff
CRC32 hash : 4AF5175E
CRC32 hash (skip zero) : 1A70DDB4
AccurateRip signature : 67AD3D15
->Accurately ripped! (confidence 6)
Track 19
Filename : /Users/davesprou/Desktop/XLD Rips/19 Various Artists - Natural Blues.aiff
CRC32 hash : 56FA0A2F
CRC32 hash (skip zero) : 7906D60C
AccurateRip signature : 8C294AB4
->Accurately ripped! (confidence 6)
End of status report
X Lossless Decoder version 20080919 (92.0)
XLD extraction logfile from 2008-09-18 17:32:12 -0400
Various Artists / Whatever - The 90's Pop & Culture Box
Used drive : MATSHITA DVD-R UJ-857E (revision ZF1E)
Use cdparanoia mode : YES (CDParanoia III 10.2 engine)
Disable audio cache : OK for the drive with cache less than 2750KB
Read offset correction : 102
Max retry count : 100
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:00 | 04:49:58 | 0 | 21732
2 | 04:49:58 | 03:15:57 | 21733 | 36414
3 | 08:05:40 | 03:41:13 | 36415 | 53002
4 | 11:46:53 | 03:15:55 | 53003 | 67682
5 | 15:02:33 | 02:47:24 | 67683 | 80231
6 | 17:49:57 | 04:12:69 | 80232 | 99200
7 | 22:02:51 | 04:28:32 | 99201 | 119332
8 | 26:31:08 | 04:46:14 | 119333 | 140796
9 | 31:17:22 | 04:33:28 | 140797 | 161299
10 | 35:50:50 | 02:53:26 | 161300 | 174300
11 | 38:44:01 | 03:25:15 | 174301 | 189690
12 | 42:09:16 | 03:58:16 | 189691 | 207556
13 | 46:07:32 | 04:06:47 | 207557 | 226053
14 | 50:14:04 | 05:28:58 | 226054 | 250711
15 | 55:42:62 | 03:33:44 | 250712 | 266730
16 | 59:16:31 | 03:27:29 | 266731 | 282284
17 | 62:43:60 | 03:59:04 | 282285 | 300213
18 | 66:42:64 | 05:03:44 | 300214 | 322982
19 | 71:46:33 | 04:13:20 | 322983 | 341977
Track 01
Filename : /Users/davesprou/Desktop/XLD Rips/01 Various Artists - Itszoweezee (Hot).aiff
CRC32 hash : 087BD8BB
CRC32 hash (skip zero) : FA76B8BF
AccurateRip signature : C15FBCD3
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 02
Filename : /Users/davesprou/Desktop/XLD Rips/02 Various Artists - Lovefool.aiff
CRC32 hash : ABE140AA
CRC32 hash (skip zero) : 3726107D
AccurateRip signature : 384E0517
->Rip may not be accurate.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 1
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 1
Duplicated bytes error (maybe fixed) : 1
Track 03
Filename : /Users/davesprou/Desktop/XLD Rips/03 Various Artists - Radiation Vibe.aiff
CRC32 hash : 56C16210
CRC32 hash (skip zero) : A7C7E4B3
AccurateRip signature : BF564A24
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 04
Filename : /Users/davesprou/Desktop/XLD Rips/04 Various Artists - The Impression That I Get.aiff
CRC32 hash : E0EC6FE4
CRC32 hash (skip zero) : 974BC3E6
AccurateRip signature : F4B69C7A
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 05
Filename : /Users/davesprou/Desktop/XLD Rips/05 Various Artists - Turn It On.aiff
CRC32 hash : 37E53DFA
CRC32 hash (skip zero) : A676F301
AccurateRip signature : AE8C1418
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 06
Filename : /Users/davesprou/Desktop/XLD Rips/06 Various Artists - Bitch.aiff
CRC32 hash : 05578D78
CRC32 hash (skip zero) : E1E54103
AccurateRip signature : BF5D2BA1
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 07
Filename : /Users/davesprou/Desktop/XLD Rips/07 Various Artists - Mmmbop.aiff
CRC32 hash : 9AC743E9
CRC32 hash (skip zero) : 308E095C
AccurateRip signature : 3A11D53F
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 1
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 08
Filename : /Users/davesprou/Desktop/XLD Rips/08 Various Artists - Brian Wilson.aiff
CRC32 hash : D1CD598B
CRC32 hash (skip zero) : D30C1AE1
AccurateRip signature : 9BD0321B
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 1
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 1
Duplicated bytes error (maybe fixed) : 1
Track 09
Filename : /Users/davesprou/Desktop/XLD Rips/09 Various Artists - Brick.aiff
CRC32 hash : BE2F2433
CRC32 hash (skip zero) : 2019BBDD
AccurateRip signature : 98F7CE24
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 10
Filename : /Users/davesprou/Desktop/XLD Rips/10 Various Artists - Sex And Candy.aiff
CRC32 hash : 401307F6
CRC32 hash (skip zero) : 4C630465
AccurateRip signature : 96EB8354
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 11
Filename : /Users/davesprou/Desktop/XLD Rips/11 Various Artists - Walkin' On The Sun.aiff
CRC32 hash : 64D0F5FF
CRC32 hash (skip zero) : 85C65FBB
AccurateRip signature : 0C334EFA
->Rip may not be accurate.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 2
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 1
Duplicated bytes error (maybe fixed) : 1
Track 12
Filename : /Users/davesprou/Desktop/XLD Rips/12 Various Artists - Tubthumping.aiff
CRC32 hash : D5E6DA12
CRC32 hash (skip zero) : 31E49FF7
AccurateRip signature : 60F72F09
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 13
Filename : /Users/davesprou/Desktop/XLD Rips/13 Various Artists - 6 Underground.aiff
CRC32 hash : 2F9465D1
CRC32 hash (skip zero) : E62270C8
AccurateRip signature : 80C5AC0D
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 14
Filename : /Users/davesprou/Desktop/XLD Rips/14 Various Artists - Lullaby.aiff
CRC32 hash : E30E9347
CRC32 hash (skip zero) : 390CD1EB
AccurateRip signature : 70F81279
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 15
Filename : /Users/davesprou/Desktop/XLD Rips/15 Various Artists - Slide.aiff
CRC32 hash : 7CB776B1
CRC32 hash (skip zero) : 7061D271
AccurateRip signature : D4E83B19
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 16
Filename : /Users/davesprou/Desktop/XLD Rips/16 Various Artists - Kiss Me.aiff
CRC32 hash : 85D8468C
CRC32 hash (skip zero) : 75B48000
AccurateRip signature : B4F5D28D
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 17
Filename : /Users/davesprou/Desktop/XLD Rips/17 Various Artists - Steal My Sunshine.aiff
CRC32 hash : 1BAE6EF2
CRC32 hash (skip zero) : 67624197
AccurateRip signature : 4E9BBBD2
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 1
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 1
Track 18
Filename : /Users/davesprou/Desktop/XLD Rips/18 Various Artists - What It's Like.aiff
CRC32 hash : 4AF5175E
CRC32 hash (skip zero) : 1A70DDB4
AccurateRip signature : 67AD3D15
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Track 19
Filename : /Users/davesprou/Desktop/XLD Rips/19 Various Artists - Natural Blues.aiff
CRC32 hash : 56FA0A2F
CRC32 hash (skip zero) : 7906D60C
AccurateRip signature : 8C294AB4
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
No errors occurred
End of status report
X Lossless Decoder version 20080919 (92.0)
XLD extraction logfile from 2008-09-18 17:52:36 -0400
Various Artists / Whatever - The 90's Pop & Culture Box
Used drive : MATSHITA DVD-R UJ-857E (revision ZF1E)
Use cdparanoia mode : YES (CDParanoia III 10.2 engine)
Disable audio cache : OK for the drive with cache less than 2750KB
Read offset correction : 102
Max retry count : 100
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:00 | 04:49:58 | 0 | 21732
2 | 04:49:58 | 03:15:57 | 21733 | 36414
3 | 08:05:40 | 03:41:13 | 36415 | 53002
4 | 11:46:53 | 03:15:55 | 53003 | 67682
5 | 15:02:33 | 02:47:24 | 67683 | 80231
6 | 17:49:57 | 04:12:69 | 80232 | 99200
7 | 22:02:51 | 04:28:32 | 99201 | 119332
8 | 26:31:08 | 04:46:14 | 119333 | 140796
9 | 31:17:22 | 04:33:28 | 140797 | 161299
10 | 35:50:50 | 02:53:26 | 161300 | 174300
11 | 38:44:01 | 03:25:15 | 174301 | 189690
12 | 42:09:16 | 03:58:16 | 189691 | 207556
13 | 46:07:32 | 04:06:47 | 207557 | 226053
14 | 50:14:04 | 05:28:58 | 226054 | 250711
15 | 55:42:62 | 03:33:44 | 250712 | 266730
16 | 59:16:31 | 03:27:29 | 266731 | 282284
17 | 62:43:60 | 03:59:04 | 282285 | 300213
18 | 66:42:64 | 05:03:44 | 300214 | 322982
19 | 71:46:33 | 04:13:20 | 322983 | 341977
Track 01
Filename : /Users/davesprou/Desktop/XLD Rips/01 Various Artists - Itszoweezee (Hot).aiff
CRC32 hash (test run) : 087BD8BB
CRC32 hash : 087BD8BB
CRC32 hash (skip zero) : FA76B8BF
AccurateRip signature : C15FBCD3
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 02
Filename : /Users/davesprou/Desktop/XLD Rips/02 Various Artists - Lovefool.aiff
CRC32 hash (test run) : 90151067
CRC32 hash : 90151067
CRC32 hash (skip zero) : 1204805B
AccurateRip signature : 8C2B7F59
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 1
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 1
Duplicated bytes error (maybe fixed) : 1
Inconsistency in error sectors : 0
Track 03
Filename : /Users/davesprou/Desktop/XLD Rips/03 Various Artists - Radiation Vibe.aiff
CRC32 hash (test run) : 56C16210
CRC32 hash : 56C16210
CRC32 hash (skip zero) : A7C7E4B3
AccurateRip signature : BF564A24
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 04
Filename : /Users/davesprou/Desktop/XLD Rips/04 Various Artists - The Impression That I Get.aiff
CRC32 hash (test run) : E0EC6FE4
CRC32 hash : E0EC6FE4
CRC32 hash (skip zero) : 974BC3E6
AccurateRip signature : F4B69C7A
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 05
Filename : /Users/davesprou/Desktop/XLD Rips/05 Various Artists - Turn It On.aiff
CRC32 hash (test run) : 37E53DFA
CRC32 hash : 37E53DFA
CRC32 hash (skip zero) : A676F301
AccurateRip signature : AE8C1418
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 06
Filename : /Users/davesprou/Desktop/XLD Rips/06 Various Artists - Bitch.aiff
CRC32 hash (test run) : 05578D78
CRC32 hash : 05578D78
CRC32 hash (skip zero) : E1E54103
AccurateRip signature : BF5D2BA1
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 07
Filename : /Users/davesprou/Desktop/XLD Rips/07 Various Artists - Mmmbop.aiff
CRC32 hash (test run) : 9AC743E9
CRC32 hash : 9AC743E9
CRC32 hash (skip zero) : 308E095C
AccurateRip signature : 3A11D53F
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 1
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 08
Filename : /Users/davesprou/Desktop/XLD Rips/08 Various Artists - Brian Wilson.aiff
CRC32 hash (test run) : D1CD598B
CRC32 hash : D1CD598B
CRC32 hash (skip zero) : D30C1AE1
AccurateRip signature : 9BD0321B
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 1
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 1
Duplicated bytes error (maybe fixed) : 1
Inconsistency in error sectors : 0
Track 09
Filename : /Users/davesprou/Desktop/XLD Rips/09 Various Artists - Brick.aiff
CRC32 hash (test run) : BE2F2433
CRC32 hash : BE2F2433
CRC32 hash (skip zero) : 2019BBDD
AccurateRip signature : 98F7CE24
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 10
Filename : /Users/davesprou/Desktop/XLD Rips/10 Various Artists - Sex And Candy.aiff
CRC32 hash (test run) : 401307F6
CRC32 hash : 401307F6
CRC32 hash (skip zero) : 4C630465
AccurateRip signature : 96EB8354
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 11
Filename : /Users/davesprou/Desktop/XLD Rips/11 Various Artists - Walkin' On The Sun.aiff
CRC32 hash (test run) : 4707A2A7
CRC32 hash : 29869C92
->Rip may not be accurate.
CRC32 hash (skip zero) : 6DF81C62
AccurateRip signature : 187A94E6
->Rip may not be accurate.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 1
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 12
Filename : /Users/davesprou/Desktop/XLD Rips/12 Various Artists - Tubthumping.aiff
CRC32 hash (test run) : D5E6DA12
CRC32 hash : D5E6DA12
CRC32 hash (skip zero) : 31E49FF7
AccurateRip signature : 60F72F09
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 13
Filename : /Users/davesprou/Desktop/XLD Rips/13 Various Artists - 6 Underground.aiff
CRC32 hash (test run) : 2F9465D1
CRC32 hash : 2F9465D1
CRC32 hash (skip zero) : E62270C8
AccurateRip signature : 80C5AC0D
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 14
Filename : /Users/davesprou/Desktop/XLD Rips/14 Various Artists - Lullaby.aiff
CRC32 hash (test run) : E30E9347
CRC32 hash : E30E9347
CRC32 hash (skip zero) : 390CD1EB
AccurateRip signature : 70F81279
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 15
Filename : /Users/davesprou/Desktop/XLD Rips/15 Various Artists - Slide.aiff
CRC32 hash (test run) : 7CB776B1
CRC32 hash : 7CB776B1
CRC32 hash (skip zero) : 7061D271
AccurateRip signature : D4E83B19
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 16
Filename : /Users/davesprou/Desktop/XLD Rips/16 Various Artists - Kiss Me.aiff
CRC32 hash (test run) : 85D8468C
CRC32 hash : 85D8468C
CRC32 hash (skip zero) : 75B48000
AccurateRip signature : B4F5D28D
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 17
Filename : /Users/davesprou/Desktop/XLD Rips/17 Various Artists - Steal My Sunshine.aiff
CRC32 hash (test run) : 1BAE6EF2
CRC32 hash : 1BAE6EF2
CRC32 hash (skip zero) : 67624197
AccurateRip signature : 4E9BBBD2
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 1
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 1
Inconsistency in error sectors : 0
Track 18
Filename : /Users/davesprou/Desktop/XLD Rips/18 Various Artists - What It's Like.aiff
CRC32 hash (test run) : 4AF5175E
CRC32 hash : 4AF5175E
CRC32 hash (skip zero) : 1A70DDB4
AccurateRip signature : 67AD3D15
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 19
Filename : /Users/davesprou/Desktop/XLD Rips/19 Various Artists - Natural Blues.aiff
CRC32 hash (test run) : 56FA0A2F
CRC32 hash : 56FA0A2F
CRC32 hash (skip zero) : 7906D60C
AccurateRip signature : 8C294AB4
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Some inconsistencies found
End of status report
The key track being 11 here.
Also note the incorrect "No errors occurred" report at the end of the second log.
By doing an invert and mix of the waveforms, it's not an audible error.
I can make that file available if it's of any use.
------ I now have about 30 perfect rips of Mmmbop --- I'm the luckiest guy in the world...
Edit - This error reminds me of a problem I had using Paranoia with the internal Matshita in my old G5 iMac.
Sort of a glitch/burp that occurs, seemingly randomly, right at the end of some tracks. It was dramatically audible in the G5 cases - pretty much just a noise/burp sound, but in one case I could clearly recognise some distorted vocal fragments from earlier in the rip. Some cache expulsion?
I'd like to check the previous problem rips I got of this CD to see if they fit glitch at the end of the track pattern, but it looks like I've deleted all those files.
This could just be a problem with paranoia and some Matshita drives.
Knucklehead, why are you not using test and copy?
Knucklehead, why are you not using test and copy?
The third log is using test and copy.
I don't think you'd see a significant ripping speed increase.
If that's truly the case with cdparanoia then I agree with you that the read ahead should not be user-configurable. It definitely isn't the case for EAC. If the read ahead was adjustable in EAC, I believe there would be worthwhile speed increase for those with drives that cache more than 64kB but far less than 2MB.
Track 11
Filename : /Users/davesprou/Desktop/XLD Rips/11 Various Artists - Walkin' On The Sun.aiff
CRC32 hash : 64D0F5FF
CRC32 hash (skip zero) : 85C65FBB
AccurateRip signature : 0C334EFA
->Rip may not be accurate.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 2
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 1
Duplicated bytes error (maybe fixed) : 1
No errors occurred
End of status report
The key track being 11 here.
Also note the incorrect "No errors occurred" report at the end of the second log.
The log report is not incorrect. Forget about the AccurateRip result for a moment. No major errors were found on this track. Only if a read or skip error is found, it is reported as failed. Those are uncorrectable errors. The errors listed below that are minor errors that are usually corrected. This is how cdparanoia has always worked.
Note track 8 from the same log:
Track 08
Filename : /Users/davesprou/Desktop/XLD Rips/08 Various Artists - Brian Wilson.aiff
CRC32 hash : D1CD598B
CRC32 hash (skip zero) : D30C1AE1
AccurateRip signature : 9BD0321B
->Accurately ripped! (confidence 6)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 1
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 1
Duplicated bytes error (maybe fixed) : 1
No major errors. Corrected minor errors; rip matched with AR. All systems go.
You can, however, choose the "Treat AccurateRip mismatch as an inconsistency in log" option.
If that's truly the case with cdparanoia then I agree with you that the read ahead should not be user-configurable. It definitely isn't the case for EAC. If the read ahead was adjustable in EAC, I believe there would be worthwhile speed increase for those with drives that cache more than 64kB but far less than 2MB.
I know from compiling different builds of cdparanoia III 9.8 -- each with a different read ahead value -- that you can safely play around with the read ahead values only within certain limits. Drop it too low, the rip results became inconsistent; the speed gain was not what I would call significant either. Take it too high above the read ahead default.... Well, I managed to completely destroy a drive by taking it up far more than is sensible. I just wanted to see what it would do. (Let's just say that I wouldn't recommend doing it!)
I'm not going to pretend to understand precisely why cdparanoia gets wonky when the read ahead values are altered to be far below and/or above its intended default spec, but I did learn that those tolerances are the way they are for a reason. It's a good idea to respect them. A user-configurable read ahead control would do more harm than good.
Track 11
Filename : /Users/davesprou/Desktop/XLD Rips/11 Various Artists - Walkin' On The Sun.aiff
CRC32 hash (test run) : 4707A2A7
CRC32 hash : 29869C92
->Rip may not be accurate.
CRC32 hash (skip zero) : 6DF81C62
AccurateRip signature : 187A94E6
->Rip may not be accurate.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 1
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
I see the problem here. In secure test before copy mode, one of the rips is a burst rip; the other is using cdparanoia. This happened before with an earlier XLD version. tmkk needs to fix this again.
[quote name='Pepzhez' post='589157' date='Sep 19 2008, 10:41']
Forget about the AccurateRip result for a moment.
[/quote]
Wouldn't this tend to confuse most users a bit more than the existence of the "use old CDParanoia engine" checkbox?
If it's an uncorrectable error, why has the disk ripped every time on this drive without Paranoia with perfect AR matches?
[quote name='Pepzhez' date='Sep 19 2008, 12:53' post='589168']
[/quote]
I see the problem here. In secure test before copy mode, one of the rips is a burst rip; the other is using cdparanoia. This happened before with an earlier XLD version. tmkk needs to fix this again.
[/quote]
Thanks. I was wondering how the test + copy mode worked. And why the speed difference in the second rip.
I didn't say it was an uncorrectable error. It isn't.
See my post above. I identified the problem. It will be fixed.
Forget about the AccurateRip result for a moment.
Wouldn't this tend to confuse most users a bit more than the existence of the "use old CDParanoia engine" checkbox?
Not if they can read and understand the options in the preference panel. XLD gives you the choice to use "Treat AccurateRip mismatch as an inconsistency in the log," if you want to use that. I don't care at all for this option because the log becomes even more confusing. You then have to check if the "inconsistencies" are AR mismatches or sector inconsistencies.
Without that option checked, XLD reports similarly to the way the EAC log does. The actual ripping results are what counts, and a log shouldn't be telling you that errors or "inconsistencies" occurred in the actual rip if they did not in fact occur.
Besides, most discs don't even exist in the AR database, so you can't always rely on AR to be your guide.
Hi,
I've been using XLD for the past week or so and discovered this forum along the way. Let me first say I'm very pleased with the rips I'm getting from XLD. However, I'm noticing a consistent problem with CDs that also contain a data - the last audio track appears to be padded (times are extended) and will always hang toward the end of the rip. This will occur whether pregap is included or excluded. Max can rip these tracks, however, and does not appear to pad out the track time. I'm not technical enough to understand what's happening here, but it is consistent and is the only issue I've found to date with XLD ripping.
Example CDs that this has occurred with:
- Fiona Apple, When The Pawn, Track 10: "I Know"
- Auf der Maur, Auf der Maur, Track 12: "I Need, I Want, I Will"
Has anyone else experienced this and found a solution/workaround?
I understand this is a feature request thread, so can I request a feature that enables XLD to rip final audio tracks on CDs that also include a data track :-) I didn't want to bombard XLD's author with seemingly random user emails but also could not find anywhere to log possible issues.
Another CD that XLD did not like is "Songs For The Deaf", Queens Of The Stone Age. It has a hidden pregap track of ~1'30" to track 1 (HTOA?) and XLD goes into a hanging state when trying to rip track 1 with pregap included or excluded in the options. Not related entirely and possibly hardware based, I know, but other CDs with small pregaps on track 1 rip okay with XLD. Max rips track 1 and ignores the pregap track. Ideally, I'd love to see XLD rip track 1 with the hidden track, but a successful track 1 rip would be a good too.
One feature request that does come to mind is the ability to specify output folder name values for the formats that you rip. For example, I'm using multiple outputs at present and would like my folders to be "flac" and "aac". At present they are "FLAC" and "MPEG-4 ACC", based on the rip format (%f). Customization of these values would be useful in this context. Not exactly top priority, but a "nice to have".
Thanks.
Previous versions of XLD didn't, but would it be possible to copy over ALL tags when transcoding from one format to another? Even non-standard ones?...Or at least the tags that iTunes can/will append to files it recognises (e.g. ALBUMSORTORDER, ITUNESCOMPILATION, etc.)
ALL is impossible, because the way to store the entry of metadata item in MP4 metadata and ID3 tag (4 bytes binary) differs from the way in ape tag and vorbiscomment (unlimited(?) length text). If you want me to do this, please list the all tags that should be supported by XLD.
Quote from tmkk XLD developer
Hoo boy. Well, correct me if I'm mistaken, but doesn't foobar copy over all tags? I know I've converted from FLAC/WavPack to AAC and MP3, and all my tags (including non-standard ones) were copied over.
I suppose
my "must-haves" would be:
ALBUM
ALBUMSORTORDER
ARTIST
ARTISTSORTORDER
BAND
COMPOSER
DISCNUMBER
GENRE
ITUNESCOMPILATION
TITLE
TOTALDISCS
TOTALTRACKS
TRACK
TRACKSORTORDER
YEAR
I'd imagine that other people have their own "must-haves" as well... I'm just thinking of the iTunes specific ones.
The format chosen should be displayed SOMEwhere other than in the preference pane so that accidental encodes aren't done (and time isn't wasted... and yes, I realise it was my own fault... but 2 CDs later... not so impressed).
Has anyone else experienced this and found a solution/workaround?
Yes, I've experienced this. This is definitely a problem with XLD. It's impossible to rip the last track of any CD that contains a data track at the end.
Yes, I've experienced this. This is definitely a problem with XLD. It's impossible to rip the last track of any CD that contains a data track at the end.
Ahh... that would explain why those two CDs won't rip entirely.
Bugger.
The format chosen should be displayed SOMEwhere other than in the preference pane so that accidental encodes aren't done (and time isn't wasted... and yes, I realise it was my own fault... but 2 CDs later... not so impressed).
What about placing the format section drop down menu in XLD's main application window(the window with decode button).
For the past several years, the OS X port of cdparanoia III 9.8 does have a method for properly ripping the last track of a multi-session CD. (This is why xACT can do it as well, as it uses this very port.)
From the README.OSX file:
Multi-session CDs are now properly supported (OS X only, though the change could be easily applied to the Linux code as well). Previously, cdparanoia would treat the end of the last track of one session as being the same as the start of the next session, which caused the inter-session gap to be included. This gap lasts about two minutes, and gets read errors (and sometimes nasty noise) near the end. Now, it checks the session lead-out to determine the end of the last track of each session.
The format chosen should be displayed SOMEwhere other than in the preference pane so that accidental encodes aren't done (and time isn't wasted... and yes, I realise it was my own fault... but 2 CDs later... not so impressed).
What about placing the format section drop down menu in XLD's main application window(the window with decode button).
I was going to suggest adding the extension of the format being created in the "Progress" window (since it displays the rest of the output filename), but that's a much better idea! It would be a much more convenient place for it to be.
Besides, most discs don't even exist in the AR database,
I don't believe this to be a true statement,
most discs are in AR, there is a % which are not, I would guess < 5%
I'm not trying to argue with you or to dismiss AR, but how in the world do you arrive at the < 5% figure? It's my experience that the vast majority of discs in my collection are not in the AccurateRip databse. Granted, my tastes run towards the obscure, but it's rare to find a lot of well-regarded jazz improv albums or 20th century composers of some renown (Stockhausen, for one) in AR.
There is also a vast world of quite famous Latin American, Indian, Middle Eastern and Asian popular music that rather surprisingly seems barely represented at all in the database.
This isn't meant as a criticism. I realize that this is solely a matter of people not submitting the results, certainly, but if you consider the sheer amount of recorded music available throughout the world, I honestly wouldn't be surprised if even 5% of all CDs ever released are in the AR database.
Perhaps in a few more years, though.
Sorry to stray so far off topic.
If you have compliant cue sheet that is correctly associated with the MP3 file XLD will allow you to convert it into another format.
are they 'losslessly' split or are they re-encoded??
No. Unless you convert the file you want to split into a lossless format. Be advised you will never be able to reconstruct the original MP3 that has been encoded but if you choose a lossless format it will preserve what you have left of the original MP3 you wish split thus being closer to the source file.
thanks for the reply. I'm looking to get everything I have currently on JR MC12 / windows (cue+mp3/flac) into itunes+mac (mp3 + alac).
XLD will help splitting flacs into alacs but for splitting mp3 without loosing quality I only know musiccutter (would be a lot of work and doesn't run on MAC). the other option is splitting mp3's into alacs which would be incredibly inefficient (storage-wise).
why don't more apps do the same as musiccutter and split mp3 without reencoding? any app on mac does this?
sorry if this is getting a bit offtpic
thanks!!
Besides, most discs don't even exist in the AR database,
I don't believe this to be a true statement, most discs are in AR, there is a % which are not, I would guess < 5%
Yeah right...
neovibe asked for a for a lossless solution using XLD. The key word here is re-encodes. I gave a solution using XLD's current capabilities as asked. The solutions that everybody has given neovibe are great and simply rewrites the file with out re-encoding(transcoding,converting) the MP3file. These applications split(slices) the existing MP3 file into several segments which then become individual tracks with no changes to audio signal other than splits including the new metadata. These applications mentioned simple automates the process. I think this should be a feature to eventually be incorporated into XLD if any of these applications source is available for use. tmkk stated XLD is an audio converter and we the users have placed the emphasis on the ripping portion of XLD here of late.
I must be very tired because the way this forum works (the software) is pretty strange at first, so my last reply was before reading all the answers.
So, ok, for mac there's fission and maybe pcutmp3 (will try to find a link via google) and for windows musiccutter. as far as I've researched these are the only apps that will get this right.
I know it's not a priority but would be very nice if xld could do all of this.
thanks for your help everyone
Not if they can read and understand the options in the preference panel. XLD gives you the choice to use "Treat AccurateRip mismatch as an inconsistency in the log," if you want to use that. I don't care at all for this option because the log becomes even more confusing. You then have to check if the "inconsistencies" are AR mismatches or sector inconsistencies.
Without that option checked, XLD reports similarly to the way the EAC log does. The actual ripping results are what counts, and a log shouldn't be telling you that errors or "inconsistencies" occurred in the actual rip if they did not in fact occur.
Besides, most discs don't even exist in the AR database, so you can't always rely on AR to be your guide.
I misread your post on the "uncorrectable" part. It makes sense now.
I'm trying some perfect condition CDs now, and 10.2 paranoia does seem to be producing the same errors as I've been getting with the slightly scratched CD that I've been using up to now. Not audible, but enough to mess up the AR report. All I've looked at so far are nearly identical blips at just before the end of the track.
For other feature issues ---
The offset listings don't don't show up if you start the program without the external drive on. If you turn on the drive you need to restart the program to get the offsets to show up, which is a bit inconvenient.
A BIG one - A good help file!
For anyone who hasn't used PC ripping programs, and is coming from using MAX, all the new things like usable logs, T+C, AR, etc, is a bit of an adjustment trying to come up with an efficient workflow.
I spoke with tmkk about creating a Users Guide that would be included in XLD's down load. This not a simple task and will take some to complete a comprehensive Users Guide. I have created a lay out design and a preliminary content outline. I do not have an estimated time of completion at the moment.
New XLD Version 20080921 released today with following features and corrections.
Fixed some issues with the new cdparanoia engine
Fixed a problem when ripping Mixed Mode CD/Enhanced CD
Removed redundancy of the cue sheet generated by XLD
Offset correction value is now set automatically when opening
I'm trying some perfect condition CDs now, and 10.2 paranoia does seem to be producing the same errors as I've been getting with the slightly scratched CD that I've been using up to now. Not audible, but enough to mess up the AR report. All I've looked at so far are nearly identical blips at just before the end of the track.
Update to 20080921 and try it now. I just tested this, and the issue has been resolved. !0.2 in secure test and copy mode is now working correctly. No more CRC mismatches.
He also fixed the enhanced CD issue. Works perfectly now!
Once again, very impressive support.
Thanks, tmkk!
I'm not trying to argue with you or to dismiss AR, but how in the world do you arrive at the < 5% figure?
It was a guess, how in the world did you come up with your 51% or more discs not in the database (world wide releases)? Would you also say that most discs are not in freedb or Musicbrainz? (for those 2 someone has to type the track names and submit, AccurateRip is pretty much automatic).
It was a guess, how in the world did you come up with your 51% or more discs not in the database (world wide releases)? Would you also say that most discs are not in freedb or Musicbrainz? (for those 2 someone has to type the track names and submit, AccurateRip is pretty much automatic).
I would say that there are many discs that are not in freedb or Musicbrainz. What's the percentage? I have no idea. They do however contain a great deal of the popular Turkish and African pop that never seem to give any AR results.
If one is dealing mainly with Anglo-American rock/pop of the less underground persuasion, it may indeed be a safe bet that AR does cover 95% of that particular field. I am sure that all 12,000 offset variations of
Dark Side of the Moon are there. Other things? Considerably less so. You'd be hard pressed to find many Derek Bailey or Cecil Taylor discs in AR. (Or around half of the Can or T.Rex discography, I noticed last week; those are not exactly ultra-obscure non-rock artists either.)
That's not a flaw with AccurateRip. Such stats merely reflect the relative ubiquity of what is popular amongst the vast majority of the AR user base. The same can be said of freedb and Musicbrainz.
Perhaps there exists a localized Chinese CD database that flips these demographics considerably. (I don't know if there really is one, but if one does exist, I believe its database would reflect rather different preferences.)
However, I didn't bring this subject up to argue about AR. It came up because I was pointing out that a ripping log shouldn't list the lack of an AR result as an error or "inconsistency," that's all.
I actually quite like AccurateRip. If only I were able to submit results with XLD, I could add quite a few titles to the database, you know.
Update to 20080921 ... fixed the enhanced CD issue. Works perfectly now!
Once again, very impressive support.
Thanks, tmkk!
Agreed. Just updated and all prior multi-session rip problems appear to be resolved. Excellent support turnaround. Still can't rip track 1 of "Songs For The Deaf" that has htoa, so hoping that will happen in a future release too.
Thanks tmkk - great stuff.
Agreed. Just updated and all prior multi-session rip problems appear to be resolved. Excellent support turnaround. Still can't rip track 1 of "Songs For The Deaf" that has htoa, so hoping that will happen in a future release too.
Thanks tmkk - great stuff.
I can rip the hidden track 0 of "Songs for the Deaf" fine so I think it has sth. to do with the capabilities of your drive.
This new option to use C2 error pointers seems really interesting. I will try a new rip using this feature to see what happens. tmkk is pushing the envelope once again with new features! Thanks tmkk you really have taken Mac users to another level in digital audio management!
Version 20080921a:
* Added option to use C2 error pointers
* When the option is turned on, XLD first read a sector in burst mode, and check the occurrence of C2 error. If C2 error occurs, then XLD re-read the sector with cdparanoia. This accelerates ripping extremely for the drive with C2 error support (Plextor, NEC, etc), without losing safety. If you use this option, please make sure that your drive supports reporting C2 errors. Modified wavpack encoder to store MD5 checksum by default
* Added option to prevent XLD from setting offset correction value automatically
Firstly, can we rely on EAC to determine the C2 reporting ability of a drive and secondly, this latest version is providing:
X Lossless Decoder version 20080921a (93.0)
XLD extraction logfile from 2008-09-21 13:48:59 +0100
The White Stripes / De Stijl
Used drive : MATSHITA DVD-R UJ-867 (revision HA13)
Use cdparanoia mode : YES (CDParanoia III 10.2 engine)
Disable audio cache : OK for the drive with cache less than 2750KB
Make use of C2 pointers : YES
Read offset correction : 102
Max retry count : 100
-------------------------------
snipped
-------------------------------
List of alternate offset correction values
# | Absolute | Relative | Confidence
------------------------------------------
1 | -565 | -667 | 31
2 | -1244 | -1346 | 20
3 | -562 | -664 | 8
These three alternate offset correction values have not appeared before and, AFAIK, are completely incorrect.
I'm trying some perfect condition CDs now, and 10.2 paranoia does seem to be producing the same errors as I've been getting with the slightly scratched CD that I've been using up to now. Not audible, but enough to mess up the AR report. All I've looked at so far are nearly identical blips at just before the end of the track.
Update to 20080921 and try it now. I just tested this, and the issue has been resolved. !0.2 in secure test and copy mode is now working correctly. No more CRC mismatches.
He also fixed the enhanced CD issue. Works perfectly now!
Once again, very impressive support.
Thanks, tmkk!
It's still there for me with the Matshita.
If I'm at all right about this being similar to the problem I had with the old paranoia and my old Matshita, I've never seen any problem remotely like that with any other drive. This might just be related to this specific hardware, which is last falls generation of iBook.
I haven't seen any cases yet of this current small glitch issue with other drives, but I haven't been trying them much - all my time I've been spending with the program has been spent looking at this issue on the Matshita.
I'm moving on now to focus the much better/faster drives that I'll actually be using for ripping.
My Plextor 230 now runs at full speed with XLD! This is great. Before the only ripper it would work at all fast with was iTunes.
Another thanks to tmkk.
I'm can see we're getting very close to where it will be worth the time to re-rip my CD collection with XLD.
------
For the old CDParanoia issue - How about label the box something like "Desperation Mode - Try only if CD cant be ripped, and can't be repaired. Might provide acceptable results"
That's about the only use I see for the old ripper.
If having the engine included is getting in the way of development, make the first small help file something to that effect, and provide a link to an old version of XLD with the old engine included.
I can rip the hidden track 0 of "Songs for the Deaf" fine so I think it has sth. to do with the capabilities of your drive.
Thanks - I did suspect the drive was at play here too. I'll need to go back and check the specifics, but I recall a >2 second pregap, albeit smaller than the Songs For The Deaf track 0, being ripped okay on the drive - an internal Matshita UJ-85J.
Out of interest, what drive are you using that successfully ripped track 0 on SFTD?
Thanks.
Out of interest, what drive are you using that successfully ripped track 0 on SFTD?
Thanks.
It's a Matshita CD-RW CW-8221.
Is performing a burst rip really an optimal method for checking possible C2 errors??
hello, macman. first and foremost, thank you for such an effective piece of software for the mac. your work will hopefully pay off soon.
i'd like to suggest a "total track" field among the tags, so that when importing to audio players it will detail, for example, "Track 5 of 17." i've also found that although there is a "disc total" field, the setting does not save correctly (at least in lame mp3.) if you have the time, would you please solve this?
also useful and time-saving would be the option to save to seperate folders when decoding to multiple formats. for example, it would be great to set "MP3" and "FLAC" subfolders within the album's main folder automatically and have the respective songs, cue and log go in each. this would make the entire process incredibly simple.
i'm sorry i've gone over my limit of feature requests, but i would also love to see the ability to export m3u playlists.
that's all for now i'm so impressed by xld; i think you've done a wonderful job, especially since you're the only coder. keep up the excellent work!
i'd like to suggest a "total track" field among the tags, so that when importing to audio players it will detail, for example, "Track 5 of 17." i've also found that although there is a "disc total" field, the setting does not save correctly (at least in lame mp3.) if you have the time, would you please solve this?
also useful and time-saving would be the option to save to seperate folders when decoding to multiple formats. for example, it would be great to set "MP3" and "FLAC" subfolders within the album's main folder automatically and have the respective songs, cue and log go in each. this would make the entire process incredibly simple.
The "comment" field also doesn't save for me when ripping to FLAC. Haven't tested the others.
And I love the second idea.
The "comment" field also doesn't save for me when ripping to FLAC. Haven't tested the others.
And I love the second idea.
Neither does the Album Artist field (I don't know what it uses, though, BAND or ALBUMARTIST).
Is performing a burst rip really an optimal method for checking possible C2 errors??
Short answer: yes.
Medium answer: yes, that's what dbpoweramp does if you enable C2.
Long answer: Technically, C2 could be used for either burst or "secure" reads.
My understanding of the difference between a burst rip and a secure rip is as follows:
1. Both rip types can and usually do use the same read command and flags/options.
2. The primary difference in a burst read vs. a secure read is in the pattern of reads for a track.
Burst reads data in approximately same-sized chunks (groups of frames) from the first frame to the last frame of a track with no backtracking and it reads the target data only once (well, unless you tell it to perform two passes, e.g. with a test & copy approach, where everything is read twice).
Secure reads a certain number of same-size chunks (groups of frames), a subset of the track, backtracks and reads them again, overlapping a small (or large) amount of data when it backtracks to provide for synchronization (lining up the data).
So, if a drive provides Accurate Stream capabilities and the capability is not buggy, then a test & copy approach with two bursts should be about as reliable at detecting non-repeatable* errors as a secure pass. And because there's only one non-optimal head reposition with burst (vs. dozens or hundreds with secure) it runs faster.
However, if a drive doesn't provide a reliable Accurate Stream capability (either it doesn't have it or the implementation is buggy), a secure rip can (or may) provide a more reliable read of the track, due primarily to synchronization when the drive doesn't align the data exactly where you asked it to do so. Double however: it is unheard of for contemporary drives to not provide Accurate Stream...but there are a very small minority of contemporary drives that have bugs with the feature on some discs.
-brendan
* of course, repeatable errors might get missed, which is why it is nice to have a drive with good C2 support where they would be caught.
hello, macman. first and foremost, thank you for such an effective piece of software for the mac. your work will hopefully pay off soon.
i'd like to suggest a "total track" field among the tags, so that when importing to audio players it will detail, for example, "Track 5 of 17." i've also found that although there is a "disc total" field, the setting does not save correctly (at least in lame mp3.) if you have the time, would you please solve this?
also useful and time-saving would be the option to save to seperate folders when decoding to multiple formats. for example, it would be great to set "MP3" and "FLAC" subfolders within the album's main folder automatically and have the respective songs, cue and log go in each. this would make the entire process incredibly simple.
i'm sorry i've gone over my limit of feature requests, but i would also love to see the ability to export m3u playlists.
that's all for now i'm so impressed by xld; i think you've done a wonderful job, especially since you're the only coder. keep up the excellent work!
hyro1 the developer of XLD is tmkk. tmkk deserves all the credit! I only try to maintain the HA members suggestions for XLD in hopefully an organized format. Please read the 1st post of this thread to familarize yourself with some the features that have been suggested and the responses from tmkk about them.
I checked the "total track" field for Lame MP3 and it appears you are correct that tag info is not being saved correctly. I will place this issue on the list for tmkk to look at. Please read the first post of this thread to learn about separate folders feature. This has already been implemented in XLD. The only issue with the feature is that if your were to select Save as single file(+cue) because you wanted to archive using a lossless format and use a lossy format for your digital audio player you can not select Include pregap in the previous track to output individual files(Both formats will be created as a Save as file(+cue).
The workaround for this is to 1st rip or save the lossless format with the following Format of filename setting located the Preference menu under the General tab to (%A/%T/%f/%T), also remember to Set the output directory to where you desire the file to be saved. Next open the lossless format that you just saved with the cue sheet and select the lossy format you want and set the Format of filename setting to (%A/%T/%f/%n %t). You should have both formats in separate folders Artist, Album, Format. Note currently the log report is placed under where you specified using Set Output directory under Preferences General tab. Just locate the log report and drag into lossless folder that you saved in the first 1st step. The log report issue will be reported tmkk.
Ability to export m3u playlists has been suggested already please check the 1st post of this thread.
WTF?!
I'm ripping absurdly fast now that the C2 option was made available and I enabled it (along with the new paranoia release).
In fact, I'm ripping faster than I have with any other ripper since I got my Mac. I know that this is supposed to be a good thing... but I feel like I'm doing something wrong!
Before I'd be lucky if I got to 5x, and now I'm averaging 10x.
As long as you are certain that your drive supports C2 properly, you're not doing anything wrong.
If your drive doesn't support C2, then you're getting incorrect CRCs for every track.
Regardless, I'm not using C2 (my Pioneer drives don't do it) and I'm still getting speeds of 10x with cdparanoia 10.2 test and copy. That's twice as fast as XLD was before cdparanoia 10.2 was integrated.
It's quite nice.
If your drive doesn't support C2, then you're getting incorrect CRCs for every track.
How so???
That's what XLD is doing with drives known not to support C2, such as the Pioneer DVR-108. I have no idea why XLD is doing that, but I'll be the first to admit that C2 ripping is an unknown area to me. Don't take my word for it. Here are some logs.
A proper test before copy rip, without C2:
X Lossless Decoder version 20080921a (93.0)
XLD extraction logfile from 2008-09-21 13:25:44 -0500
The Beatles / The Beatles (White Album) [Disc 1]
Used drive : PIONEER DVD-RW DVR-108 (revision 1.17)
Use cdparanoia mode : YES (CDParanoia III 10.2 engine)
Disable audio cache : OK for the drive with cache less than 2750KB
Make use of C2 pointers : NO
Read offset correction : 48
Max retry count : 100
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:33 | 02:43:07 | 33 | 12264
2 | 02:43:40 | 03:56:38 | 12265 | 30002
3 | 06:40:03 | 02:17:67 | 30003 | 40344
4 | 08:57:70 | 03:08:63 | 40345 | 54507
5 | 12:06:58 | 01:01:25 | 54508 | 59107
6 | 13:08:08 | 03:05:50 | 59108 | 73032
7 | 16:13:58 | 04:45:15 | 73033 | 94422
8 | 20:58:73 | 02:43:45 | 94423 | 106692
9 | 23:42:43 | 02:28:52 | 106693 | 117844
10 | 26:11:20 | 02:03:20 | 117845 | 127089
11 | 28:14:40 | 02:18:23 | 127090 | 137462
12 | 30:32:63 | 02:04:27 | 137463 | 146789
13 | 32:37:15 | 03:41:18 | 146790 | 163382
14 | 36:18:33 | 03:42:05 | 163383 | 180037
15 | 40:00:38 | 01:41:35 | 180038 | 187647
16 | 41:41:73 | 01:46:02 | 187648 | 195599
17 | 43:28:00 | 02:54:15 | 195600 | 208664
List of alternate offset correction values
# | Absolute | Relative | Confidence
------------------------------------------
1 | 193 | 145 | 77
2 | -74 | -122 | 8
3 | 746 | 698 | 8
4 | 898 | 850 | 5
Track 02
Filename : /Test1b/02 - Dear Prudence.wav
CRC32 hash (test run) : A77425E0
CRC32 hash : A77425E0
CRC32 hash (skip zero) : 64E2BAA8
AccurateRip signature : 667DE9A8
->Accurately ripped! (confidence 16)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 03
Filename : /Test1b/03 - Glass Onion.wav
CRC32 hash (test run) : 6AC2C412
CRC32 hash : 6AC2C412
CRC32 hash (skip zero) : 172F1133
AccurateRip signature : 0573A933
->Accurately ripped! (confidence 18)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
No errors occurred
End of status report
Now here's what happens when I engage C2. (Yes, I know that it is widely reported that this drive does not support C2):
X Lossless Decoder version 20080921a (93.0)
XLD extraction logfile from 2008-09-21 13:36:54 -0500
The Beatles / The Beatles (White Album) [Disc 1]
Used drive : PIONEER DVD-RW DVR-108 (revision 1.17)
Use cdparanoia mode : YES (CDParanoia III 10.2 engine)
Disable audio cache : OK for the drive with cache less than 2750KB
Make use of C2 pointers : YES
Read offset correction : 48
Max retry count : 100
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:33 | 02:43:07 | 33 | 12264
2 | 02:43:40 | 03:56:38 | 12265 | 30002
3 | 06:40:03 | 02:17:67 | 30003 | 40344
4 | 08:57:70 | 03:08:63 | 40345 | 54507
5 | 12:06:58 | 01:01:25 | 54508 | 59107
6 | 13:08:08 | 03:05:50 | 59108 | 73032
7 | 16:13:58 | 04:45:15 | 73033 | 94422
8 | 20:58:73 | 02:43:45 | 94423 | 106692
9 | 23:42:43 | 02:28:52 | 106693 | 117844
10 | 26:11:20 | 02:03:20 | 117845 | 127089
11 | 28:14:40 | 02:18:23 | 127090 | 137462
12 | 30:32:63 | 02:04:27 | 137463 | 146789
13 | 32:37:15 | 03:41:18 | 146790 | 163382
14 | 36:18:33 | 03:42:05 | 163383 | 180037
15 | 40:00:38 | 01:41:35 | 180038 | 187647
16 | 41:41:73 | 01:46:02 | 187648 | 195599
17 | 43:28:00 | 02:54:15 | 195600 | 208664
Track 02
Filename : /Test1b/02 - Dear Prudence(1).wav
CRC32 hash (test run) : 9AC60E89
CRC32 hash : 9AC60E89
CRC32 hash (skip zero) : EFF8313A
AccurateRip signature : D61FD2B7
->Rip may not be accurate.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 03
Filename : /Test1b/03 - Glass Onion(1).wav
CRC32 hash (test run) : 17B37529
CRC32 hash : 17B37529
CRC32 hash (skip zero) : 53106564
AccurateRip signature : 3DBDC490
->Rip may not be accurate.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
No errors occurred
End of status report
Note the entirely different CRCs. Also note how the second log informs you that no errors occurred ... but the second log is still wrong (and AccurateRip backs me up on this). I can easily repeat (and have repeated) this behavior with any disc on this drive and the two others I've tried it with. (None of the drives support C2, according to the DAE Database.)
ffooky pointed this out the other day, in this very thread:
http://www.hydrogenaudio.org/forums/index....st&p=589395 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=65809&view=findpost&p=589395)
ffooky pointed this out the other day, in this very thread:
http://www.hydrogenaudio.org/forums/index....st&p=589395 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=65809&view=findpost&p=589395)
Not exactly.
The suspect alternate offsets indicated the problem. If he would've looked a little deeper, he would have noticed that something was amiss with the individual track CRC hashes.
As far as I remember the CRCs and Accuraterip confidences were all kosher, it was just those alternate offsets that were worthy of note. I'll rip the same disc, same settings again and check.
I ripped the disc again with C2 utilised and without. The results were identical and, look as deeply as I can, I see nothing amiss with the CRC hashes.
X Lossless Decoder version 20080921a (93.0)
XLD extraction logfile from 2008-09-24 12:57:07 +0100
The White Stripes / De Stijl
Used drive : MATSHITA DVD-R UJ-867 (revision HA13)
Use cdparanoia mode : YES (CDParanoia III 10.2 engine)
Disable audio cache : OK for the drive with cache less than 2750KB
Make use of C2 pointers : YES
Read offset correction : 102
Max retry count : 100
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:00 | 01:50:45 | 0 | 8294
2 | 01:50:45 | 02:36:15 | 8295 | 20009
3 | 04:26:60 | 03:06:62 | 20010 | 34021
4 | 07:33:47 | 02:13:23 | 34022 | 44019
5 | 09:46:70 | 03:09:72 | 44020 | 58266
6 | 12:56:67 | 04:29:68 | 58267 | 78509
7 | 17:26:60 | 02:51:62 | 78510 | 91396
8 | 20:18:47 | 03:14:43 | 91397 | 105989
9 | 23:33:15 | 04:22:05 | 105990 | 125644
10 | 27:55:20 | 01:58:30 | 125645 | 134524
11 | 29:53:50 | 01:53:45 | 134525 | 143044
12 | 31:47:20 | 03:22:22 | 143045 | 158216
13 | 35:09:42 | 02:31:68 | 158217 | 169609
List of alternate offset correction values
# | Absolute | Relative | Confidence
------------------------------------------
1 | -565 | -667 | 31
2 | -1244 | -1346 | 20
3 | -562 | -664 | 8
Track 01
Filename : /Users/daniellinhart/Documents/Conversions/01 The White Stripes - You're Pretty Good Looking (For A Girl).wav
CRC32 hash : CA34AA96
CRC32 hash (skip zero) : 86DC9CC9
AccurateRip signature : F477171E
->Accurately ripped! (confidence 14)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 02
Filename : /Users/daniellinhart/Documents/Conversions/02 The White Stripes - Hello Operator.wav
CRC32 hash : FE871446
CRC32 hash (skip zero) : 6BDF1FE5
AccurateRip signature : 6F635A60
->Accurately ripped! (confidence 14)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 03
Filename : /Users/daniellinhart/Documents/Conversions/03 The White Stripes - Little Bird.wav
CRC32 hash : 4091B0A2
CRC32 hash (skip zero) : 752FF5C2
AccurateRip signature : CA7A3022
->Accurately ripped! (confidence 14)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 04
Filename : /Users/daniellinhart/Documents/Conversions/04 The White Stripes - Apple Blossom.wav
CRC32 hash : D03CAEDB
CRC32 hash (skip zero) : 4EA05498
AccurateRip signature : E6A37FB5
->Accurately ripped! (confidence 14)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 05
Filename : /Users/daniellinhart/Documents/Conversions/05 The White Stripes - I'm Bound to Pack it Up.wav
CRC32 hash : 94C47B5C
CRC32 hash (skip zero) : 851E1F2B
AccurateRip signature : 569997EE
->Accurately ripped! (confidence 14)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 06
Filename : /Users/daniellinhart/Documents/Conversions/06 The White Stripes - Death Letter.wav
CRC32 hash : 120BE9FD
CRC32 hash (skip zero) : F84AF65C
AccurateRip signature : F69A0358
->Accurately ripped! (confidence 14)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 07
Filename : /Users/daniellinhart/Documents/Conversions/07 The White Stripes - Sister, Do You Know My Name?.wav
CRC32 hash : 8D2EEA32
CRC32 hash (skip zero) : 4E82E76A
AccurateRip signature : 99589B16
->Accurately ripped! (confidence 14)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 08
Filename : /Users/daniellinhart/Documents/Conversions/08 The White Stripes - Truth Doesn't Make A Noise.wav
CRC32 hash : 0804B104
CRC32 hash (skip zero) : B4E5671D
AccurateRip signature : 25A5FF7D
->Accurately ripped! (confidence 14)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 09
Filename : /Users/daniellinhart/Documents/Conversions/09 The White Stripes - A Boy's Best Friend.wav
CRC32 hash : CAEC3274
CRC32 hash (skip zero) : 9B85EB93
AccurateRip signature : 6DCDC5EB
->Accurately ripped! (confidence 14)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 10
Filename : /Users/daniellinhart/Documents/Conversions/10 The White Stripes - Let's Build A Home.wav
CRC32 hash : C36A2820
CRC32 hash (skip zero) : F62C1A8A
AccurateRip signature : 324A9D01
->Accurately ripped! (confidence 14)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 11
Filename : /Users/daniellinhart/Documents/Conversions/11 The White Stripes - Jumble, Jumble.wav
CRC32 hash : 3E6034B0
CRC32 hash (skip zero) : 9B9BE9A9
AccurateRip signature : 7B940611
->Accurately ripped! (confidence 14)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 12
Filename : /Users/daniellinhart/Documents/Conversions/12 The White Stripes - Why Can't You Be Nicer To Me?.wav
CRC32 hash : 17195713
CRC32 hash (skip zero) : 9E830602
AccurateRip signature : CBF1A3CD
->Accurately ripped! (confidence 14)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 13
Filename : /Users/daniellinhart/Documents/Conversions/13 The White Stripes - Your Southern Can Is Mine.wav
CRC32 hash : 10402539
CRC32 hash (skip zero) : 8201D677
AccurateRip signature : 6BCB092F
->Accurately ripped! (confidence 14)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
No errors occurred
End of status report
Anyone else noticed that the log is now named after the last track on the disc rather than the disc itself ?
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Moderation: Changed code to codebox.[/size]
I ripped the disc again with C2 utilised and without. The results were identical and, look as deeply as I can, I see nothing amiss with the CRC hashes.
...
Anyone else noticed that the log is now named after the last track on the disc rather than the disc itself ?
Yes, I also noticed that about the log naming.
Hmmmm. Is the Matshita UJ-867 acknowledged to be a good C2 ripping drive?
I have two Pioneer drives, and both drives produce the different set of CRCs for each and every track whenever I enable C2.
What settings are you using? Test before copy? Verify suspicious sectors? Both?
I wonder why I'm getting these bizarre results?
Hmmmm. Is the Matshita UJ-867 acknowledged to be a good C2 ripping drive?
I don't know about good but EAC passed it as using C2.
What settings are you using? Test before copy? Verify suspicious sectors? Both?
I use Verify suspicious sectors and Test before copy only when track does not exist in AccurateRip DB
I've always trusted the Pioneer drive in my eMac over any of the slot loaders but it seems the rather crappy Matshitas are actually superior for at least some purposes. Never thought I'd see the day
BTW, does the log I posted above appear in a little scrollable box to everyone but me or have I missed a setting to make it appear so ?
Just tried again using a Pioneer DVR-K05; this time turning off test before copy and verify suspicious sectors. Same thing again.
X Lossless Decoder version 20080921a (93.0)
XLD extraction logfile from 2008-09-24 08:42:49 -0500
The Beatles / The Beatles (White Album) [Disc 1]
Used drive : PIONEER DVD-RW DVR-K05 (revision Q523)
Use cdparanoia mode : YES (CDParanoia III 10.2 engine)
Disable audio cache : OK for the drive with cache less than 2750KB
Make use of C2 pointers : NO
Read offset correction : 48
Max retry count : 100
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:33 | 02:43:07 | 33 | 12264
2 | 02:43:40 | 03:56:38 | 12265 | 30002
3 | 06:40:03 | 02:17:67 | 30003 | 40344
4 | 08:57:70 | 03:08:63 | 40345 | 54507
5 | 12:06:58 | 01:01:25 | 54508 | 59107
6 | 13:08:08 | 03:05:50 | 59108 | 73032
7 | 16:13:58 | 04:45:15 | 73033 | 94422
8 | 20:58:73 | 02:43:45 | 94423 | 106692
9 | 23:42:43 | 02:28:52 | 106693 | 117844
10 | 26:11:20 | 02:03:20 | 117845 | 127089
11 | 28:14:40 | 02:18:23 | 127090 | 137462
12 | 30:32:63 | 02:04:27 | 137463 | 146789
13 | 32:37:15 | 03:41:18 | 146790 | 163382
14 | 36:18:33 | 03:42:05 | 163383 | 180037
15 | 40:00:38 | 01:41:35 | 180038 | 187647
16 | 41:41:73 | 01:46:02 | 187648 | 195599
17 | 43:28:00 | 02:54:15 | 195600 | 208664
List of alternate offset correction values
# | Absolute | Relative | Confidence
------------------------------------------
1 | 193 | 145 | 77
2 | -74 | -122 | 8
3 | 746 | 698 | 8
4 | 898 | 850 | 5
Track 02
Filename : /C2 test/02 - Dear Prudence.wav
CRC32 hash : A77425E0
CRC32 hash (skip zero) : 64E2BAA8
AccurateRip signature : 667DE9A8
->Accurately ripped! (confidence 16)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 03
Filename : /C2 test/03 - Glass Onion.wav
CRC32 hash : 6AC2C412
CRC32 hash (skip zero) : 172F1133
AccurateRip signature : 0573A933
->Accurately ripped! (confidence 18)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
No errors occurred
End of status report
X Lossless Decoder version 20080921a (93.0)
XLD extraction logfile from 2008-09-24 08:48:56 -0500
The Beatles / The Beatles (White Album) [Disc 1]
Used drive : PIONEER DVD-RW DVR-K05 (revision Q523)
Use cdparanoia mode : YES (CDParanoia III 10.2 engine)
Disable audio cache : OK for the drive with cache less than 2750KB
Make use of C2 pointers : YES
Read offset correction : 48
Max retry count : 100
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:33 | 02:43:07 | 33 | 12264
2 | 02:43:40 | 03:56:38 | 12265 | 30002
3 | 06:40:03 | 02:17:67 | 30003 | 40344
4 | 08:57:70 | 03:08:63 | 40345 | 54507
5 | 12:06:58 | 01:01:25 | 54508 | 59107
6 | 13:08:08 | 03:05:50 | 59108 | 73032
7 | 16:13:58 | 04:45:15 | 73033 | 94422
8 | 20:58:73 | 02:43:45 | 94423 | 106692
9 | 23:42:43 | 02:28:52 | 106693 | 117844
10 | 26:11:20 | 02:03:20 | 117845 | 127089
11 | 28:14:40 | 02:18:23 | 127090 | 137462
12 | 30:32:63 | 02:04:27 | 137463 | 146789
13 | 32:37:15 | 03:41:18 | 146790 | 163382
14 | 36:18:33 | 03:42:05 | 163383 | 180037
15 | 40:00:38 | 01:41:35 | 180038 | 187647
16 | 41:41:73 | 01:46:02 | 187648 | 195599
17 | 43:28:00 | 02:54:15 | 195600 | 208664
Track 02
Filename : /C2 test/02 - Dear Prudence(1).wav
CRC32 hash : 9AC60E89
CRC32 hash (skip zero) : EFF8313A
AccurateRip signature : D61FD2B7
->Rip may not be accurate.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 03
Filename : /C2 test/03 - Glass Onion(1).wav
CRC32 hash : 17B37529
CRC32 hash (skip zero) : 53106564
AccurateRip signature : 3DBDC490
->Rip may not be accurate.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
No errors occurred
End of status report
I can only conclude that these Pioneer drives and C2 really don't like each other. Why the different CRCs, though? Doesn't make sense to me. Oh, well.
ffooky, could you try comparing a track (C2 and non-C2) with your Pioneer drive? I'm wondering if all Pioneer drives do this.
Just noticed something. All of these C2 ripped WAVs are screwed up. It's the XLD endian problem again.
DVR-106D DVD-RW
DV-107D DVD±R/RW
DVR-108 DVD±R/RW
DVR-112 DVD±R/RW
According to DAE Drive Features Database the Pioneer drives listed above do not support C2 Error Correction. Pephez your drive is an earlier model not listed. Your drive appears not to play nice with C2 like these other Pioneer drives. Note the next Pioneer model listed is DVR-115 and it breaks ranks with other models in that it is listed as supporting C2 Error Correction.
Pepzhez are you using a PPC?
I only just noticed that all of these C2 rips are producing WAVs with the wrong endian. There was a similar endian problem with certain discs with a previous XLD build. It was due to a libcdio bug that only affected PPC G5 machines. I'm thinking that this is related.
I just sent tmkk an email letting him know about this.
tmkk just released a new XLD version Version 20080924:
* Fixed a problem that produced endian-swapped audio files on PPC machine when using C2 pointers
* Updated LAME to version 3.98.2
Try this version!
And to think he just got my email 2 seconds ago..... How's THAT for a quick update?
Just kidding. He's obviously one step ahead of me.
EDIT: The update fixed it.
X Lossless Decoder version 20080924 (93.1)
XLD extraction logfile from 2008-09-24 09:35:30 -0500
The Beatles / The Beatles (White Album) [Disc 1]
Used drive : PIONEER DVD-RW DVR-K05 (revision Q523)
Use cdparanoia mode : YES (CDParanoia III 10.2 engine)
Disable audio cache : OK for the drive with cache less than 2750KB
Make use of C2 pointers : YES
Read offset correction : 48
Max retry count : 100
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:33 | 02:43:07 | 33 | 12264
2 | 02:43:40 | 03:56:38 | 12265 | 30002
3 | 06:40:03 | 02:17:67 | 30003 | 40344
4 | 08:57:70 | 03:08:63 | 40345 | 54507
5 | 12:06:58 | 01:01:25 | 54508 | 59107
6 | 13:08:08 | 03:05:50 | 59108 | 73032
7 | 16:13:58 | 04:45:15 | 73033 | 94422
8 | 20:58:73 | 02:43:45 | 94423 | 106692
9 | 23:42:43 | 02:28:52 | 106693 | 117844
10 | 26:11:20 | 02:03:20 | 117845 | 127089
11 | 28:14:40 | 02:18:23 | 127090 | 137462
12 | 30:32:63 | 02:04:27 | 137463 | 146789
13 | 32:37:15 | 03:41:18 | 146790 | 163382
14 | 36:18:33 | 03:42:05 | 163383 | 180037
15 | 40:00:38 | 01:41:35 | 180038 | 187647
16 | 41:41:73 | 01:46:02 | 187648 | 195599
17 | 43:28:00 | 02:54:15 | 195600 | 208664
List of alternate offset correction values
# | Absolute | Relative | Confidence
------------------------------------------
1 | 193 | 145 | 77
2 | -74 | -122 | 8
3 | 746 | 698 | 8
4 | 898 | 850 | 5
Track 02
Filename : /C2 test/02 - Dear Prudence(3).wav
CRC32 hash : A77425E0
CRC32 hash (skip zero) : 64E2BAA8
AccurateRip signature : 667DE9A8
->Accurately ripped! (confidence 16)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 03
Filename : /C2 test/03 - Glass Onion(3).wav
CRC32 hash : 6AC2C412
CRC32 hash (skip zero) : 172F1133
AccurateRip signature : 0573A933
->Accurately ripped! (confidence 18)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Drift error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
No errors occurred
End of status report
So now the question is: if these Pioneer drives are reported not to be C2-compatible with EAC, does that necessarily apply to XLD as well? A shame that there's no way to actually test C2 compatibility with XLD (or with anything else on OS X).
A shame that there's no way to actually test C2 compatibility with XLD (or with anything else on OS X).
Pepzhez - I'm not sure on compatibility of C2, but I have been able to report ability of C2 or otherwise using the drutil command. There's a lot of config info it will spit out for your drive that you can trawl through. A specific one to get C2 capabilities is the following.
drutil getconfig supported | grep -i c2
The result of this command for my drive (Mashita UJ-85J) is the following.
[blockquote]Logical unit will return C2 error data[/blockquote]
It might be good to start a separate thread for XLD results with different drives, and keep this more for feature requests.
Also might be good to start a XLD use questions thread. Could be useful until the help files come along --- and actually help build them.
-------
Feature request - Make user definable offsets part of the auto offset function. I just got a drive that isn't included, and I really miss the nice brainless quality of the auto setting.
-------
Back to drives.... My Plextor, and even more so, my brand new Lite-On are working great!
knucklehead I started a thread about drives already. At the time no one seemed to be interested Here is a link (http://www.hydrogenaudio.org/forums/index.php?showtopic=65894)
I added your feature suggestion to the list!
knucklehead I started a thread about drives already. At the time no one seemed to be interested. Here is a link (http://www.hydrogenaudio.org/forums/index.php?showtopic=65894)
A bit different.
Drive use results with all the logs and whatnot. And not limited to OEM drives (who want's to be limited to them ... ).
knucklehead I started a thread about drives already. At the time no one seemed to be interested. Here is a link (http://www.hydrogenaudio.org/forums/index.php?showtopic=65894)
A bit different.
Drive use results with all the logs and whatnot. And not limited to OEM drives (who want's to be limited to them ... ).
Thats a good idea to include log reports with the drive information. I started a new thread about drive use results with all the logs. I also started a XLD Master Thread to help organize all the important threads about XLD such as: The Drive use results with all the logs,Feature Suggestions, OEM Drives and other relevant threads that have been posted. This way new users will have an easier time finding all the important threads that the older HA XLD users are already aware of.
Thanks
@macmanforhire: Great idea. Can we also have a thread to capture found problems with XLD, which is slightly different to feature requests? I'm not keen on polluting the feature request thread with these items.
Thanks.
mookr just posted the Master Thread List. I will add a found problems and bug list. You know Mac users want everything simply and laid out for them, or at least thats why I bought a Mac!
A shame that there's no way to actually test C2 compatibility with XLD (or with anything else on OS X).
Pepzhez - I'm not sure on compatibility of C2, but I have been able to report ability of C2 or otherwise using the drutil command. There's a lot of config info it will spit out for your drive that you can trawl through. A specific one to get C2 capabilities is the following.
drutil getconfig supported | grep -i c2
The result of this command for my drive (Mashita UJ-85J) is the following.
[blockquote]Logical unit will return C2 error data[/blockquote]
Note: remember that there's a separate transaction to ask the drive if it supports C2 error pointers. That's different than the transaction to request (well, flag in the Read CD command really) that the C2 error pointers be delivered via a Read CD command.
In addition to that difference, there's the quality and reliability of the C2 pointers returned. This, in turn relates to the entire data reading/analysis chain that takes the reflected light, turns it into signal, digitizes the signal, decodes the signal into raw data, syncs and reorganizes the data from raw into various cooked formats, and in parallel performs error detection and correction using C1, C2, CIRC, etc. That all varies from drive model to drive model and sometimes firmware to firmware.
My point being that yes, you should verify that a drive reports that it supports C2 before you start requesting the supplementary C2 error pointers when you request reads, but that does not mean you should automatically feel comfortable with the quality/accuracy of the C2 data being delivered.
The daefeatures.co.uk database is a good start, but again, you really need to test several drives with the tool using a known scratched disc to get a feel for the quality of the reads the drives make (with and without the C2 error pointers to help the software focus on the problem areas).
-brendan
Note: remember that there's a separate transaction to ask the drive if it supports C2 error pointers ...
-brendan
Brendan - thanks for the detailed information. I'm not familiar with the low level details of C2 at all - I've been searching for a way on OS X to see if a drive can report on C2 or not and drutil was the only way I've found so far. Of course, several layers of implementation aspects make the story far trickier. Your information is valuable - anyway we can have a primer on C2 and its foibles put in the wiki?
Is there one drive that "does it all" or is that a/the holy grail of drives?! I'm searching for a SATA one right now and getting this level of detail in order to make a decision is very difficult it seems.
When transcoding individual files have XLD respect the Format of filename structure.
Your information is valuable - anyway we can have a primer on C2 and its foibles put in the wiki?
We can make a dedicated page to C2 errors and how exactly they work. Before I wrote the Secure Ripping page I was actually unsure about them. The only problem is we would need feedback from the community, because there isn't much out there about the low underlying structure of what exactly C1/C2 errors are. To discuss C2 error's, besides the fact that they are read-errors from a compact disc we would have to go into what exactly Reed-Solomon codes are and then after that everything just get's real messy without having a degree in Comp. Sci or EE for that matter. My point is basically if we can get some feedback from the more experienced users on here I would be happy to put another wiki page together.
Option for it to automagically query its databases for metadata, rather than having to be told to go look.
These features will be implemented (priority is low).
Quote from tmkk XLD developer
I'm not sure if this is the same thing, but it would be nice if XLD would save downloaded/modified metadata to its OWN database for retrieval later. As it stands, if XLD hangs during a rip, and has to be shut down, any modifications made to downloaded metadata have too be re-entered... which is time-consuming.
EDIT:
Also, the ability to cancel or skip the pregap detection when mounting a disc would be nice. Maybe having the option to detect the pre-gap AFTER editing metadata, etc.
Ability to switch to Gracenote info if you already used freedb.
Although the Gracenote feature is fairly idiot proof once you know to have iTunes open, I'm stuck with a lot of freedb tags in XLD that I can't seem to replace with the much better Gracenote offerings.
@ ozmosis82 I added both your suggestion to the list. I think it would be great to have a safety net like that when editing metadata.
@ knucklehead I added your suggestion to the list. It would be convenient to allow you to switch form the freedb tags to Gracenote tags.
I would like to suggest to add the ability to search albumartexchange.com for album art. This site has higher resolution album art images that have been cleaned up. The Album Art Exchange database of album art seems to growing at a rapid pace. I think this would a great asset to add to XLD allowing the user to get retrieve more consistent quality album art.
@ ozmosis82 I added both your suggestion to the list. I think it would be great to have a safety net like that when editing metadata.
@ knucklehead I added your suggestion to the list. It would be convenient to allow you to switch form the freedb tags to Gracenote tags.
I would like to suggest to add the ability to search albumartexchange.com for album art. This site has higher resolution album art images that have been cleaned up. The Album Art Exchange database of album art seems to growing at a rapid pace. I think this would a great asset to add to XLD allowing the user to get retrieve more consistent quality album art.
Here a vote for something like Max's iTunes metadata scripting unless it turns out I am the only one for whom the "open iTunes first" thing does not always work.
Ability to switch to Gracenote info if you already used freedb.
Although the Gracenote feature is fairly idiot proof once you know to have iTunes open, I'm stuck with a lot of freedb tags in XLD that I can't seem to replace with the much better Gracenote offerings.
Seconded. The ability to select GraceNote as an option (and also force a re-read of GraceNote in certain situations) would be very useful. I've found an issue with multi-session disks (listed on the issue thread) that would have benefited greatly from enabling a re-read of GraceNote specifically.
Add to log the peak level for each track (EAC log does).
Apparently CDs from different pressings, even though from the same master, can have different CRCs. They would have the same peak levels so that info in the log could aid verification.
tim.lance I added your feature suggestion to the list. I have not heard from tmkk in sometime. I last sent him an email on 9/26/08 but have not heard back from him. I will try another email soon. I hope everything is ok he always replied to emails very quickly. I just don't won't bother him. I hope is just taking some time for himself and everything is ok.
tim.lance I added your feature suggestion to the list. I have not heard from tmkk in sometime. I last sent him an email on 9/26/08 but have not heard back from him. I will try another email soon. I hope everything is ok he always replied to emails very quickly. I just don't won't bother him. I hope is just taking some time for himself and everything is ok.
Actually just heard back from him and if, in Preferences, under the CD Rip tab, the user ticks "Scan ReplayGain," the info is shown. I'm getting corroboration from some folks that such would suffice for their needs/wants. Will get back to you.
Please bring back the ability to convert to MP3, I used this program a ton for that
Please display the audio source (filename) when a cue-sheet is loaded.
I have a few feature requests for XLD that all relate to batch processing large amounts of music. I have used MAX to convert our 1.5TB FLAC project to MP3 and now am converting from FLAC to ALAC and am considering using XLD.
The first is to encourage a previous request about adding the ability to select folders and multiple subfolders for conversion with a single click.
The 2nd is an option to move all other non-music files to the new folder that is created. A feature to select the type of files I'd like moved would be best, as I don't want to bring files like shntool.txt or .md5. files to my MP3 folders. However, I'd love to bring all my text files with recording info, my gif and jpg ticket stubs, and any other artwork over automatically. I am dealing with 1,000's of folders so 1 at a time is quite a feat.
I'll give an example of the whole process which will give an example of all my feature requests.
I have a year of concerts that I'd like to convert. The folder is called 1997. In 1997 I have 153 folders, all named to etree standards for live concerts (ph1997-11-21.86507.flac16) and with embedded FLAC tags.
What I'd absolutely love to do is convert an entire year at a time, have the folders be created by XLD reflect the FLAC tags that are properly in place. I'd also like XLD to find all non music files (preferably the ones I specify) and bring them over as well so I don't have to manually drag over files between 1,000's of folders (again!). The tags create a folder that is named different than the one the FLAC is in, batching this process is very hard after the fact.
I cannot seem to find a way to have XLD create a folder during the conversion and renamed according to the embedded tags.
For example, when I rip the tagged FLACs inside the folder: ph1997-11-21.86507.flac16 to MP3 using Max, the result is a folder titled: 1997-11-21 - Hampton Coliseum - Hampton, VA. Similarly, Track 1 looks like this as a FLAC: ph1997-11-21d1t01.flac and like this after MAX converts it: 01 Emotional Rescue.mp3.
Where MAX doesn't perform is differentiating between two folders like this:
ph1997-11-21.16623.flac16
ph1997-11-21.86507.flac16
When converted using MAX they are piled into a single folder. My music players notice this difference either either. So I manually change the folders when there are duplicates to show the audio source. At least when they are loaded into Cog the tracks are not 01 01, 02 02 which helps.
1997-11-21 - Hampton Coliseum - Hampton, VA [AKG 460]
and
1997-11-21 - Hampton Coliseum - Hampton, VA [AUD Microtech Gafelle m210]
I've manually added to the folder names for all shows with more than one audio source. For example, this show has 4 sources and the FLAC folders look like this:
ph1997-11-21.16623.flac16
ph1997-11-21.86507.flac16
ph1997-11-21.87303.flac16
ph1997-11-21.89645.flac16
It would be super swell if 4 folders were created upon conversion in this instance but I imagine that's a longshot when it comes to having a say in what happens in relationship with the tags. I'm not sure how these can be tagged without breaking etree standards.
Otherwise, I am very pleased with XLD, it runs really well on my MacPro and would love to set all 8 of these brains loose and see how well she performs over a long haul like this.
Cheers!
I don't know why (or perhaps if) this hasn't been suggested, but I really, really think XLD should have an "Eject Disc" function.
...and yes... I realise I could just hit the eject key on my keyboard.
I really like how XLD will resize coverart when embedding into each individual file.
I mainly use XLD to convert from FLAC to ALAC.
I would also like to see the following:
- Better batch encoding support - Currently, If I want to perform a pseudo batch convert, I drag all the files onto XLD. I have XLD set up to to prompt me for tag changes before converting. Unfortunately, this means that I have to set tags manually for EVERY file.
A better option would be a batch window where you could set tags for several files at once by highlighting multiple files and batch editing tags (Similar to Max).
- Support for iTunes method of indicating that an album is Gapless.
- Support for the iTunes Compilation tag (this may not actually be necessary as setting the Album Artist tag to "Various Artists" may accomplish the same thing. Please ignore this suggestion if this is indeed the case).
why don't more apps do the same as musiccutter and split mp3 without reencoding? any app on mac does this?
sorry if this is getting a bit offtpic
Software
MP3 Trimmer for Mac OS-X does exactly this [excellent!] job.
Splits MP3 files into desired pieces without re-encoding mpeg, and even much more.
http://www.deepniner.net/mp3trimmer/ (http://www.deepniner.net/mp3trimmer/)
Also unregistered version works well, only annoying delay counter is applied.
Undocumented feature is splitting a file according the regular CUE file. Just drop CUE on the app icon, then you'll be prompted for MP3-Audio file. Then proceed. I do not have latest 2.8.8 version, but in previous one did not work well file tagging and naming.
Feature Suggestions
I'm missing very important feature. I can't understand how this could have been so completely ignored:
Handling of Pre-Emphasis (PRE flag)XLD does not write this on CUE!
Incorrect handling of this flag produces similar effect like playback of Dolby B encoded cassette without decoding.
Minor UI tweak: how about a button to check/uncheck all tracks.
Hello
I have a suggestion to make:
I would like to have the possiblity to save the current setting as a profile.
Sometimes, I like to rip a CD and then I use special setting
Sometimes, I just convert and for this I use different settings again.
For this reason, I could save settings in a profile, it is very easy and fast to reload what I need or even access different profiles from a pulldown menu.
Does this sound reasonable?
Cheers, trex
By the way, this is the greatest Sound Conversion and Ripping Tool for the Mac. Just great
Hello
I have a suggestion to make:
I would like to have the possiblity to save the current setting as a profile.
Sometimes, I like to rip a CD and then I use special setting
Sometimes, I just convert and for this I use different settings again.
For this reason, I could save settings in a profile, it is very easy and fast to reload what I need or even access different profiles from a pulldown menu.
Does this sound reasonable?
Cheers, trex
By the way, this is the greatest Sound Conversion and Ripping Tool for the Mac. Just great
Profiles. Excellent idea.
I'm writing the guy.
Hello
I have a suggestion to make:
I would like to have the possiblity to save the current setting as a profile.
Sometimes, I like to rip a CD and then I use special setting
Sometimes, I just convert and for this I use different settings again.
For this reason, I could save settings in a profile, it is very easy and fast to reload what I need or even access different profiles from a pulldown menu.
Does this sound reasonable?
Cheers, trex
By the way, this is the greatest Sound Conversion and Ripping Tool for the Mac. Just great
Profiles. Excellent idea.
I'm writing the guy.
I think profiles would make XLD a really unique tool (it is already).
If the guy does indeed profiles, I will send a nice donation
Cheers, trex
Hi,
I noticed that in the changelog for version 2003/03/30 support for the "ALBUM ARTIST" metadata for some formats was added, however this doesn't seem to be the case for FLAC -> ACC.
Is it possible that this could be added to the list of metatags that is created when converting to ACC?
Cheers
XLD rocks my world, and it would rock it even harder if:
- After ripping a CD in test & copy mode, it could display the CRCs and any mismatches for all tracks right at the top of the log, kind of like EAC does in its main window (instead of having to scroll through the entire log and visually scan each track summary for mismatches).
Thanks for the great work!
Hi...
How about adding albumartexchange.com as a source of artwork. Compared to amazon and google, the quality (and resolution) is much better. There would have to be some sort of selection policy (maybe a set preference) for which image should be chosen. Or just make it part of the album details selection pane?
XLD is excellent!!!
Hi, thanks for the great effort and commitment with the XLD development, is an excellent application for Mac.
I think it has been suggested before, but anyway: Add to XLD CD Rip log the peak level for each track (similar to EAC one).
And I have some questions:
- Why is not recommended to activate "Scan ReplayGain" option in XLD? (normalize?)
- Is there any official guide to rip with XLD?
Thanks in advance, regards
XLD rocks!!!
Add multiple output processes a la Max. I often have occasion to go to FLAC, ALAC, and AAC and love doing it in one fell swoop with Max. More, to be able to choose different output locations for these formats.
You can certainly select multiple output formats and then create separate directories for each format.
For multiple encodings in one rip pass:
Under the Preferences>General tab, see the format choices at "Output Format."
Select each of your desired formats, and set the options as you like them in turn. Then choose "Multiple Formats." Finally, click the "option" button and select each of the formats you'd like to create next time you rip.
For creating multiple directories in the above process:
Under the Preferences>General tab, choose the "format of file name>specify" button. Then, if you put the conversion format in the output file string (using %f) you can make separate directories for each format, and each directory will include the file type in its name. This has been available for many, many versions already.
Also, if you hover over the format box, a list of possible strings will appear as a tooltip (this behavior is pretty recent.)
Hi...
How about, if its possible, a "drive speed throttle"?
I guess many of us, including me, like/want our drives to go at top speed when ripping. But just ocassionaly I have found the possible benefit of lowering the drive speed. Mainly because of the noise and vibration.
I have an external drive and sometimes during ripping the thing sounds like it's about to take off!
Does anybody know the max usable speed through USB2? (Doing some quick math I guesstimate somewhere 20x or 22x. No? CD x1 = 150Kb, max USB2 thput ~ 30 MBs....)
???
Can we have the XLD time out or give up after a certain number of attempts to rip a track?
I have searched everywhere and posted this question in this forum and no answers anywhere.
When I use XLD it will ocassionally get stuck on a certain track while it is ripping an entire CD. It will stay on that track attempting to rip it FOREVER.
The only way I can stop it is to go to the program and manually cancel that track.
This is somewhat difficult since I am running a Mac Mini as a music server and I do not have a keyboard or screen....
Skibum
Does anybody know the max usable speed through USB2? (Doing some quick math I guesstimate somewhere 20x or 22x. No? CD x1 = 150Kb, max USB2 thput ~ 30 MBs....)
Where do you get ~30 MB/s as the max USB 2.0 bus speed? That's only 240 Mb/s - the max 2.0 bus speed is double that.
Although the ripping speed on my Mac mini never gets above ~18X or so as XLD encodes as it rips (and my mini is "only" a 1.66 GHz Core Duo), my WinXP laptop at work routinely hits ~42X (~60 Mb/s) on the last track of 70 min+ CDs with EAC ripping in burst mode to a temp WAV with a Lite-On USB 2.0 drive.
Can we have the XLD time out or give up after a certain number of attempts to rip a track?
I have searched everywhere and posted this question in this forum and no answers anywhere.
When I use XLD it will ocassionally get stuck on a certain track while it is ripping an entire CD. It will stay on that track attempting to rip it FOREVER.
The only way I can stop it is to go to the program and manually cancel that track.
This is somewhat difficult since I am running a Mac Mini as a music server and I do not have a keyboard or screen....
Skibum
Have you tried going Preferences > CD Rip > Max retry count, and adjusting downward?
For myself, I use a hung up rip as an invitation to go to work on repairing the CD.
Can we have the XLD time out or give up after a certain number of attempts to rip a track?
I have searched everywhere and posted this question in this forum and no answers anywhere.
When I use XLD it will ocassionally get stuck on a certain track while it is ripping an entire CD. It will stay on that track attempting to rip it FOREVER.
The only way I can stop it is to go to the program and manually cancel that track.
This is somewhat difficult since I am running a Mac Mini as a music server and I do not have a keyboard or screen....
Skibum
Have you tried going Preferences > CD Rip > Max retry count, and adjusting downward?
For myself, I use a hung up rip as an invitation to go to work on repairing the CD.
I have it set to 1. It seems to have no effect what so ever.
It was at 100.
I agree I do have some CD's that are not in the best shape. But I guess that is not is not the issue.
I would think that if XLD can not rip a track because CD track is unreadable it will skip it and move on to the next one.
I use dbPoweramp on my PC. The tracks that get stuck indefinately using XLD on my MAC have problems
on dbpoweramp also, but after a set number of tries dbpoweramp moves on to the next track.
?
Thanks!
Skibum
I'm assuming the tracks that you are having trouble with, you would prefer to have some usable rip from, rather than simply skipping them.
From my experience, the biggest factors in how well a CD rips, are the state of the CD, and the drive used to rip with.
You could try using different drives, which would cost some money. Repairing the CD's, which can be nearly free, but takes a bit of time and effort.
You might also try using the "Use old CDparanoia engine" in XLD. It might be a long shot, but there have been cases where it has produced usable rips where the new engine hangs.
You might also want to try out Rip (http://sbooth.org/Rip/) which has some fault tolerance built into it. I prefer XLD for other reasons, but you might find Rip suits you.
I'm assuming the tracks that you are having trouble with, you would prefer to have some usable rip from, rather than simply skipping them.
From my experience, the biggest factors in how well a CD rips, are the state of the CD, and the drive used to rip with.
You could try using different drives, which would cost some money. Repairing the CD's, which can be nearly free, but takes a bit of time and effort.
You might also try using the "Use old CDparanoia engine" in XLD. It might be a long shot, but there have been cases where it has produced usable rips where the new engine hangs.
You might also want to try out Rip (http://sbooth.org/Rip/) which has some fault tolerance built into it. I prefer XLD for other reasons, but you might find Rip suits you.
Well yes, I would like some type of usable rip but my first preference is to not hang the computer indefinitely.
Why is XLD not skipping a faulty track if I have set the number of retries to 1? I will try using the old CDparanoia engine.
Is there any other settings I should look at?
If It has to skip a track that would be OK. On the disks that happens I can try to rip them with dbPoweramp on my PC.
I tried Max to rip but preferred XLD. I saw Rip but since it is still in Beta I didn't give it a try. Maybe I will!
Thanks again -
skibum
Hi,
This is my first post here. I'm liking XLD and plan on using it to import my cds to a hardrive as wavs. I like the log file particularly for checking the track levels as I not a big fan of overly loud cds, especially some of the remasters of the oldies.
I see in the new version that we can now see the ISRC codes. Would any know what the command is to view those? In fact, it would be nice to see what else is new in yesterday's update (May 16th).
Please add support for ReplayGain tags on Ogg Vorbis files using vorbisgain (http://sjeng.org/vorbisgain.html).
Assuming our illustrious developer is still tracking this thread...
- Additional vote for placing a summary of all of the AccurateRip results at the bottom of the log report in addition to underneath each track. Even better would be to add a column to the Main window or Progress window with an 'AcurateRip' check mark for successful accurate rips and an 'x' if not.
- Some documentation, onegai shimasu, even if very very basic and simple. I believe this is key to supporting growth and increased usage of XLD beyond the current set of core users. As a new user of XLD, and given the rapid pace of development, it is very difficult to know the pros/cons of the various options and how to configure XLD for a particular end result. In my case this certainly makes me very apprehensive about using XLD in that I could rip all my CDs only to find a more appropriate configuration at a later date. I want to use XLD but I need better feedback in how to use it correctly.
- A way to drag and drop images if CDDB does not find one (perhaps this is implemented but a bug is preventing it from working on my system).
Domo Arigato
how add with GRACENOTE the tags? why??? the composer field are need it for me! and others dont fill composer tag! please help!
Is there any way to set in Apple Lossless settings the bit depth resample in order to make a file from 24 bit to 16 bit? iPod do not support 24 bit files.
Besides the time I could save having multiple profiles, I have found a couple of minor issues.
When reading from metadata, XLD uses the tag DISCTOTAL.
When reading from a cue sheet, XLD uses REM TOTALDISCS.
Not a huge deal, but I have both CD images and individual files and would like them to be consistent.
I have to set the compilation box manually when converting CD images using cue sheets. It would be nice if XLD would set the compilation flag when PERFORMER is Various Artists and each song has an additional PERFORMER listed.
When I use XLD it will ocassionally get stuck on a certain track while it is ripping an entire CD. It will stay on that track attempting to rip it FOREVER.
I have this problem all the time and have found only one solution...I boot into windows and use EAC. Most of the discs that I have trouble ripping with XLD rip just fine using EAC.
Feature Suggestions
I'm missing very important feature. I can't understand how this could have been so completely ignored:
Handling of Pre-Emphasis (PRE flag)
XLD does not write this on CUE!
Incorrect handling of this flag produces similar effect like playback of Dolby B encoded cassette without decoding.
I would also be most gratious if this could be implemented.
- Add output MP3 (along with v0, v1, v2… presets) to command-line version, as well as being able to specify external JPEG album art.
I need a one stop solution in Mac OS X to batch convert CUE + FLAC to properly tagged MP3 (including album art). Anybody knows any? Even a bash script would do…
- Reports and Album art (when right-clicked and "saved as…") should have same name scheme as specified in Preferences > Name format.
I rip to flac + cue, with name format %a - %t (which results in Artist - Album title), but Reports and Album Art are just saved as Album title. Getting things organized require extra renaming work…
- Add output MP3 (along with v0, v1, v2… presets) to command-line version, as well as being able to specify external JPEG album art.
I need a one stop solution in Mac OS X to batch convert CUE + FLAC to properly tagged MP3 (including album art).
I reply to myself: duh! the GUI can already batch export, although it does not embed album art (File > Open… choose multiple CUE files).
It'd be great if it did, speaking of which I'd like to choose whether to use the art embedded in the FLAC file or a sidecar JPEG with equal name (I'd actually use the latter).
Any way not to loose per-track comments when exporting/saving CUE sheet?
I was dismayed that it was happening after adding per-track comments (in classical music) to quite a few CDs.
Or else, any way to manually edit the CUE sheets to add per-track comments that XLD will recognize, and embedd into MP3's ID3 when exporting as such?
Here's my features request:
- Apple Lossless bit resample options (for instance to do 24 bit->16 bit along with frequency resample which is already present).
- Option to erase original files after conversion: if I'm transcoding my lossless collection to AAC and would like to automatically delete flac from hard drive there should be an option. Same if you go Apple Lossless -> AAC it doesn't overwrite it just like it would do on Windows, even with "overwrite" setting on. Maybe there is some setting i haven't noticed.
I have a question before I bother going into my suggestions. Is this thread still being monitored?
It doesn't look like the OP maintains the first post but I wanto know if someone capable of implementing our suggestions is still watching.
I have a question before I bother going into my suggestions. Is this thread still being monitored?
It doesn't look like the OP maintains the first post but I wanto know if someone capable of implementing our suggestions is still watching.
I believe it is, i made a suggestion about the option to erase original source files after conversions and it was implemented in the latest update =)
Well these are the things I'd like.
- Different user profiles! (I know it has been suggested already - but it's by far the best suggestion I have seen/can think of.)
- The ability to save a .cue by default (similar to the way you can automatically save .log files)
- The ability to tag an album details from a MusicBrainz/Discogs catlogue number of your CD. (Foobar has a plugin like this - it's great.)
- Fix the setting "Don't prompt if multiple candidates are found" - it doesn't work for me (currently).
- Button to cancel rip in the progress window.
- Accurate Rip v2 support (Already got it?)
- Drag'n'Drop of image files (Has it already got this?)
It's already a fantastic program, and with the introduction of "profiles" it would literally be my one stop converting and ripping program.
I found a serious flaw! XLD that allows the use of AccurateRip AND the ability to edit the read offset correction.
This will result is inaccurate rips, not good, nor acceptable.
I also have a suggestion stolen straight from EAC. Once AccurateRip is activated in the user cannot change the drive offset settings.
Also can I suggest stopping XLD from defaulting back to the last drive settings used if it can't find the new drives offsets (for users with more than one drive)?
Does XLD has any kind of "MP4 optimize" setting? It doesn't seem to automatically do that and I can't seem to find that setting anywhere.
My request:
- for the GROUPING tag on FLAC files to be transferred to the MP3 conversions of those files
Most of the basic tags transfer perfectly from FLAC to MP3 via XLD (ARTIST, ALBUMARTIST, GENRE, COMMENT, etc.), but the GROUPING tag does not carry over to the MP3 files when transcoding from FLAC. Perhaps it has something to do with the naming of the GROUPING tag in Vorbis Comments vs. ID3?
My request:
- for the GROUPING tag on FLAC files to be transferred to the MP3 conversions of those files
Wow that was fast. I post this, then three days later it appears in an update. I love XLD!
It would be wonderful if XLD would read the CD-Text information from the disc and include it in the CUE file. It doesn't seem that XLD is currently reading this information, as discs which I know have CD-Text information (verified using EAC or dBpoweramp) don't shown any track titles until after the CDDB query. I'm guessing at least some of the CD-Text is being read due to the "Don't detect pregap, ISRC, and MCN" option (which I have unchecked). For some reason the ISRC never makes it into the CUE file though. Browsing through the code it appears it's intended to. Bug perhaps?
I've also noticed that XLD will sometimes include the INDEX 00 marker and sometimes not. Using EAC with the same disc/drive the resulting CUE file will often have a number of markers which XLD missed.
Once the CD-Text can be read and included in the CUE file, having the option to disable CDDB data in the CUE file would be excellent - the goal being to try and reproduce the original as closely as possible. Having the additional option to include the CDDB data in the log would be a bonus.
Currently what I am doing to accomplish all this is rip a disc using XLD to a single file, then use EAC (in Fusion) with CDDB disabled to generate a CUE file. If there is no CD-Text I delete all the extra TITLE and PERFORMER lines from the EAC generated CUE file. For the whole process I use an old USB Plextor CD-RW drive.
@tmkk Thanks for the awesome work!
The new build - Version 20101107 (124.1) - has a good idea - multiple format encoding at the same time. This is a great idea but unfortunately there are some issues with it's current implementation.
1. It places all the encoded files into the same folder - this is extremely inconvenient. Ideally they would be placed in different folders within the output directory, and the folder names appended with the encoder setting.
2. Most annoying of all - it alters the filenames! It adds the encoder setting to each individual filename - this is very undesirable. Ideally it should leave the filenames unchanged.
If these issues were resolved and XLD behaved as I suggested (each encode to a different labelled folder), then XLD would be the only encoder required on ANY platform.
Many thanks!
The new build - Version 20101107 (124.1) - has a good idea - multiple format encoding at the same time. This is a great idea but unfortunately there are some issues with it's current implementation.
1. It places all the encoded files into the same folder - this is extremely inconvenient. Ideally they would be placed in different folders within the output directory, and the folder names appended with the encoder setting.
2. Most annoying of all - it alters the filenames! It adds the encoder setting to each individual filename - this is very undesirable. Ideally it should leave the filenames unchanged.
If these issues were resolved and XLD behaved as I suggested (each encode to a different labelled folder), then XLD would be the only encoder required on ANY platform.
Many thanks!
I agree with this, a great feature but needs some minor changes to put them in folders and just edit the folder names.
Will XLD be updated for native 64 bit code?
Please, could you improve the AccurateRip reporting, like EAC. With EAC it's easy to tell if the entire album passed AccurateRip, because EAC inserts a line at the end of the log: "All tracks accurately ripped"
With XLD, you must look through the confusing record of each individual track, with all that non-useful stuff about errors that were not found. If the XLD developers would only insert a summary line at the bottom it would make checking logs much simpler.
Version 20101117:
Fixed a disc open failure on some drives
AccurateRip summary section has been added in the log
The new build - Version 20101107 (124.1) - has a good idea - multiple format encoding at the same time. This is a great idea but unfortunately there are some issues with it's current implementation.
XLD has been able to do that for some time now.
1. It places all the encoded files into the same folder - this is extremely inconvenient. Ideally they would be placed in different folders within the output directory, and the folder names appended with the encoder setting.
Again, I've been doing things this way for ages now:
%a - %T (%y) [%f]/%n - %t
Moreover, when you select multiple formats to output in preferences, you can edit the string that appears in %f. Just to make sure I wasn't losing the plot, I've just ripped the first three tracks from an album that happened to be on my desk. I accepted the defaults for the multiple decodes, so the strings would need tidying for a full rip.
Steven Wilson - Insurgentes (2009) [FLAC (level 8)]
Steven Wilson - Insurgentes (2009) [LAME MP3 (VBR-new quality 0.0)]
Steven Wilson - Insurgentes (2009) [MPEG-4 AAC (CVBR 256kbps)]
And the tracknames all read as they should, which is <track number> - <track title>.<suffix>
2. Most annoying of all - it alters the filenames! It adds the encoder setting to each individual filename - this is very undesirable. Ideally it should leave the filenames unchanged.
Works perfectly for me using the above. Maybe I'm missing something?
Edit: typos
By far the biggest issue for me with XLD, as much as I love it and use it often, is the lack of profile selection. Switching from ripping to transcoding is a royal pain in the backside.
By far the biggest issue for me with XLD, as much as I love it and use it often, is the lack of profile selection. Switching from ripping to transcoding is a royal pain in the backside.
Agreed, I periodically switch between FLAC image ripping and ripping to individual FLAC and AAC tracks. Then there are the times when I want to encode that FLAC image to individual AAC. Being able to quickly switch between profiles of encode and naming settings would be a great addition.
I suppose this would be possible now by manually swapping out the prefs file, though that's less than ideal.
I suppose this would be possible now by manually swapping out the prefs file, though that's less than ideal.
That's how I'm doing it at the moment, but it's not a pleasant workflow, particularly when you forget to copy the prefs back before the next session.
I agree with this, a great feature but needs some minor changes to put them in folders and just edit the folder names.
See my comments above, it works fine out of the box with a little tweaking.
For the progress shown, is it possible instead of using percentage to maybe say what sector is being read and whether it is retrying to read something? I'm sitting here with '2938:37' remaining and wondering what is happening - is the drive retrying many times? is is stuck on a sector or has it slowed down reading it? I hear a lot of people talk about XLD 'hanging' when in reality the lack of feedback and lack of obvious progress is giving the appearance of 'nothing happening'.
I suppose this would be possible now by manually swapping out the prefs file, though that's less than ideal.
I just had a thought. Assuming the CLI version isn't horribly out of date, and it can transfer tags from files during transcodes, it would be relatively easy to write a script to transcode files to iTunes, leaving XLD to do the heavy lifting of ripping.
I just had a thought. Assuming the CLI version isn't horribly out of date, and it can transfer tags from files during transcodes, it would be relatively easy to write a script to transcode files to iTunes, leaving XLD to do the heavy lifting of ripping.
The CLI is very out of date (last updated over 3 years ago). I'd love it if I could rip, convert, and compare to the AR database (including checking for alternate offsets) with the CLI tool.
The CLI is very out of date (last updated over 3 years ago).
I figured that, but also wondered if it mattered.
I thought that maybe the CLI just manages the transcode/encode and passing the tags, but it's the GUI that's had the most work and not the encoding engine.
Would be nice to get the author's feedback on this one.
I thought that maybe the CLI just manages the transcode/encode and passing the tags, but it's the GUI that's had the most work and not the encoding engine.
For transcoding this is probably true, but that leaves out ripping, verifying, and offsetting.
For transcoding this is probably true, but that leaves out ripping, verifying, and offsetting.
I think I might be able to live with that, though.
That would simplify my workflow. It means I could set up XLD for the best rips possible, and encode to multiple formats, then set up scripts for the CLI for when I need to transcode files into iTunes.
I'll do some testing this week and report back, though it has to be said my scripting skills aren't all that.
For the first time I had the chance to use the "Edit tags before convert" option under Preferences > Metadata. I had 15 FLACs that I had selected for converting to ALACs, but the FLACs had missing metadata. So I enabled this option and was presented with the tags window. Unfortunately, since the file name wasn't displayed in the window, I couldn't tell which FLAC I was on in the group I selected, making entering metadata very hard. While doing this, I also thought of a change that could make entering metadata from scratch much easier. So, I have 2 suggestions:
1) In the Edit Metadata window, display the file name of the track that's being operated on.
2) Carry over filled-in metadata to subsequent tracks if no metadata exists (this can be user-configurable; i.e. either show the metadata that's embedded or carry over metadata that's been previously been filled in from a previous track. The embedded artwork should be shown and should be also be changeable. Check out how Max does this; it's not perfect )by far), but it's much better than XLD at this activity.
I feel these changes will make it much easier to add consistent metadata without constant cut/paste operations. And please don't suggest that I use iTunes (or some such) to fill in the metadata. I'd rather fill in as much metadata with XLD as possible, since I'm converting on my local HD. My music is on a NAS that I access wirelessly, so slow read/writes are the norm here.
Thanks for a great program! I'm a contributor; it makes me very happy to do some small part to keep XLD on its way to super greatness (it's already great ).
The progress window needs some enhancements:
1) Make it a true GUI window, not a simple list output. When I'm re-encoding tracks on my hard drive, the lack of an adjustable column width for the track name makes all tracks look the same in the Progress window. Because of this, it's impossible to pick the correct track to cancel, since all the track names display the same.
2) Global Pause, Resume and Quit buttons, along with the same for each entry on the Progress window.
3) With this nice GUI box would come the ability to neatly display and search (filter) the output. I regularly convert hundreds of tracks at the same time, so this would be a welcome addition. In fact, any changes to the Progress window would be welcome
Thanks for reading.
When selecting multiple files (flac, ape, etc.) for re-encoding, XLD should present me with an all-in-one track list, metadata, and album art window before re-encoding. I should be able to change the metadata, add album art, and review the track names, order and times. This is how Max functions with selecting multiple tracks, and is the reason why I use Max instead of XLD for this function. I would like to use XLD, but this birds-eye view functionality is not there (the "edit tags before convert" option under Preferences > Metadata is not the same, and usually crashes XLD when I use it).
in the CD rip window, some way to "uncheck all" would be nice. that way, if you only want to rip one track, you don't have to click on each checkbox (but one).
in iTunes, cmd-clicking on one checkbox will check/uncheck all.
in the CD rip window, some way to "uncheck all" would be nice. that way, if you only want to rip one track, you don't have to click on each checkbox (but one).
in iTunes, cmd-clicking on one checkbox will check/uncheck all.
Right click on any track or group of tracks and you will be able to check or uncheck those selected as well as the entire list.
first off, i love this application. its truly an incredible application. thank you for its continual development.
the only feature that i would love that is missing (correct me if im wrong or am missing it) is the ability for XLD to output the files in a folder that is the same as the input. Example, if i where converting the record New Wave by Against Me!, it would be nice if i could add that record to the conversion window of XLD, and XLD would then create a folder named Against Me! while putting all the output files within another folder called New Wave within the Against Me! folder, instead of just outputting the raw files in which we then manually create the folder structure.
thank you again for the amazing work.
instead of just outputting the raw files in which we then manually create the folder structure
Can't you do this with the strings I posted on the previous page?
I have maybe an unusual and small request. Compare the two files below, and notice the bitrates:
Come Together | The Beatles | Abbey Road | 4:20 | Rock | 149 kbps
Bloom | Radiohead | The King of Limbs | 5:15 | Rock | 114 kbps (VBR)
Both files were encoded as AAC. The Beatles song was done on a Windows PC using dbPowerAmp & qtaacenc, configured for QuickTime TVBR 68. The second was done with XLD also using QuickTime TVBR 68. What I'm wondering is why the Beatles song shows 149 kbps for it's average bitrate, while the Radiohead song shows 114 kbps (VBR), and is there some way to not have the (VBR) part display/be written to the file. I know all of my files are going to be VBR and really would rather not waste the column space repeating that info. I pasted some output from MediaInfo if that helps. Thanks.
Beatles song:
General
Count : 275
Count of stream of this kind : 1
Kind of stream : General
Kind of stream : General
Stream identifier : 0
Count of audio streams : 1
Audio_Format_List : AAC
Audio_Format_WithHint_List : AAC
Audio codecs : AAC LC
Audio_Language_List : English
Complete name : 01 Come Together.m4a
File name : 01 Come Together.m4a
File extension : m4a
Format : MPEG-4
Format : MPEG-4
Format/Extensions usually used : mp4 m4v m4a m4b m4p 3gpp 3gp 3gpp2 3g2 k3g jpm jpx mqv ismv isma f4v
Commercial name : MPEG-4
Format profile : Base Media / Version 2
InternetMediaType : audio/mp4
Codec ID : mp42
Codec ID/Url : http://www.apple.com/quicktime/download/standalone.html (http://www.apple.com/quicktime/download/standalone.html)
Codec : MPEG-4
Codec : MPEG-4
Codec/Extensions usually used : mp4 m4v m4a m4b m4p 3gpp 3gp 3gpp2 3g2 k3g jpm jpx mqv ismv isma f4v
Writing application : qtaacenc 20100307, QuickTime 7.6.6
Radiohead song:
General
Count : 272
Count of stream of this kind : 1
Kind of stream : General
Kind of stream : General
Stream identifier : 0
Count of audio streams : 1
Audio_Format_List : AAC
Audio_Format_WithHint_List : AAC
Audio codecs : AAC LC
Audio_Language_List : English
Complete name : 01 Bloom.m4a
File name : 01 Bloom.m4a
File extension : m4a
Format : MPEG-4
Format : MPEG-4
Format/Extensions usually used : mp4 m4v m4a m4b m4p 3gpp 3gp 3gpp2 3g2 k3g jpm jpx mqv ismv isma f4v
Commercial name : MPEG-4
Format profile : Apple audio with iTunes info
InternetMediaType : audio/mp4
Codec ID : M4A
Codec ID/Url : http://www.apple.com/itunes/ (http://www.apple.com/itunes/)
Codec : MPEG-4
Codec : MPEG-4
Codec/Extensions usually used : mp4 m4v m4a m4b m4p 3gpp 3gp 3gpp2 3g2 k3g jpm jpx mqv ismv isma f4v
Writing application : X Lossless Decoder 20110212, QuickTime 7.6.6, True VBR Quality 68
These two features have jut be added. Simply amazing application.
Implemented a profile manager. Now you can save frequently used settings as a profile and quickly switch them through the profile menu.
Added support for reading cue sheet associated with multiple files (aka "noncompliant" cuesheet)
Re-add the shortcut "Control + D" to start extraction (or a similar shortcut).
Make it easier to see what profile you are currently using (eg with a tick next to the one currently implemented).
Cheers.
PS: I hope everyone is using the new ripping engine - it owns!
When selecting multiple output formats, it would be nice to be able to use different filename formats for each one. I use different filenames for FLAC (image) and AAC (tracks) so using multiple formats won't work for me.
I like the new profile feature, but I would like to see the following changes made to profiles, the ability to save changes to an existing profile. That is unless I am doing something wrong. Also with profiles, I made a profile to transcode from FLAC to multiple formats, but it doesnt save my name changes within the multiple formats section. For example, when I am working in Multiple formats I change Mpeg-4 aac 320kps... to AAC, but when I save the whole profile, it reverts back to the long spelled out format, and it only seems to happen with aac.
support for creating m3u, ffp, sfv, and md5.
Support for MKA (Matroska Audio).
http://www.matroska.org/technical/guides/faq/index.html (http://www.matroska.org/technical/guides/faq/index.html)
Q: What is the advantage of using the .mka file instead of the original audio formats, like mp2, mp3 etc?
A: In many cases there is not a reason to store audio only files in MKA. If you have an audio file with a single track, or "song", that you don't intend to edit.
Here are some reasons that placing audio in MKA is useful:
1. The tags will be the same no matter what audio format you use. That means that if you write a program to read back tags, it only has to read them from one type of tagging system, no matter what type of audio is being used.
2. All tracks to a CD can be in a single file. You have the option of dividing the tracks into seperate Tracks, or seperate Chapters. You could make your own compilation in a single file, even using different audio formats, such as MP3 and Vorbis.
3. If you write a program to read audio of of MKA, then you don't need to understand how the framing works in the different formats because it is already done for you in Matroska.
4. It is easy to delete portions of the audio without reencoding because you just throw away those blocks. You don't even have to be able to play that format back, you could edit by just knowing timecodes.
5. Detecting differences between two audio streams would be easy because you could store both in a single file, start playback, and then just switch between tracks.
6. If you intend to combine the audio with video, then having is in MKA means you can merge it with an MKV, even if the application doesn't support the audio type.
7. In the case of MP3, MP2 AC3 and even some AAC, using "compressed headers" the MKA file may even be smaller than the original "raw" file, without losing any bit of information.
It's too late to read 11 pages sorry...may I request that checkboxes and radio buttons need to be clicked specifically 'on target' rather than simply somewhere on the text line as I find it too easy to change things without meaning to and end up having to reload profiles just to make sure things are as they were.
XLD is an awesome piece of software that continues to amaze me, thank you!
When will XLD be updated with lame 3.99?
When will XLD be updated with lame 3.99?
You can d/l the bundle and insert it by right clicking XLD -> Show package contents, and replacing the included XLDLameOutput.bundle with the version from XLD.
Thorolf
I've just seen that, thank you!
Hi,
First many thanks for this great software.
Is it possible to add these features (first one is the most important):
- Possibility to choose between "Append Gaps to Previous Track" or "Append Gaps to Next Track" (as in EAC) and generate/save cuesheet file as a single file according to the selected Gaps setting.
- MusicBrainz integration for accurate metadata.
Many Thanks in advance
Kind Regards
Right now, it's possible to rip either individual tracks, or a complete CD with the track markers as chapters. What I really really needs is the ability to rip, say, tracks 4-6 as one file, with the track markers as chapters. I.e., extend the functionality of the full CD + chapters in one file to multiple tracks + chapters in one file.
I originally used EAC on Windows for years after getting a Mac because there was nothing really equivalent. Then Rip came out and I used that. Have just switched to XLD, and very very happy: a big thumbs up. The reason I want the above feature is for classical music. It makes absolutely no sense to have, e.g., the three movements of a concerto as three different files: for resuming an interrupted work, for shuffling, for sorting, it makes sense to have them joined as one file, but with chapters. Right now, I'm forced to run XLD with whole CD + chapters, and then trim the resulting file. Very laborious. The above would fix this problem.
It would be wonderful if XLD would read the CD-Text information from the disc and include it in the CUE file.
@tmkk Thanks for the awesome work!
I'd also love to see CD-Text readable from CD and DDP. ISRC and UPC are already passed through from both, so I was surprised to find the CD Text missing. Have had to revert to EAC to get that, but much prefer working on a Mac with XLD.
This is a large request but I would love to see integration with the CueTools database (CTDB). I only recently started using CueTools and it is extremely useful to have another source when your rip appears to be free of major errors (CRC mismatches and the like) but has no AccurateRip matches or does not match. Integration of the error correction would be great, too.
Can we please have two file name options:
1. For compilations:
Compilations/%T/%a - %T - %n - %t
2. for Artist
%A/%T/%a - %T - %n - %t
Hi,
is there anybody there still coding?
It would be useful to export metadata into a file that you could later import from?