Skip to main content
Topic: XLD Requested Features List (Read 151269 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

XLD Requested Features List

Reply #75
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.


XLD Requested Features List

Reply #77
In the "lossless split" issue, my favorite Mac app is Fission... Not free, though...
It handles cue sheets beautifully!

XLD Requested Features List

Reply #78

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.

XLD Requested Features List

Reply #79
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.

XLD Requested Features List

Reply #80
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.

XLD Requested Features List

Reply #81
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?

XLD Requested Features List

Reply #82
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.

XLD Requested Features List

Reply #83

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? .

XLD Requested Features List

Reply #84
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.

XLD Requested Features List

Reply #85

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?

XLD Requested Features List

Reply #86
Here are some excerpts from this recent post:
http://www.hydrogenaudio.org/forums/index....st&p=588543

Code: [Select]
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.

Code: [Select]
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
Code: [Select]
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.

XLD Requested Features List

Reply #87
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.

XLD Requested Features List

Reply #88
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.

XLD Requested Features List

Reply #89
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.

XLD Requested Features List

Reply #90
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.
Is 24-bit/192kHz good enough for your lo-fi vinyl, or do you need 32/384?

XLD Requested Features List

Reply #91
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.

XLD Requested Features List

Reply #92
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.

XLD Requested Features List

Reply #93
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?

XLD Requested Features List

Reply #94
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.

XLD Requested Features List

Reply #95
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.)

XLD Requested Features List

Reply #96

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?

XLD Requested Features List

Reply #97
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.

XLD Requested Features List

Reply #98

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.

XLD Requested Features List

Reply #99
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.

 
SimplePortal 1.0.0 RC1 © 2008-2019