Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: XLD did it again! (Read 22601 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

XLD did it again!

I'm very pleased to announce that the last version of XLD [Version 20080907a (86.1)] became the Holy Grail of lossless audiophile on Mac OS X. In many aspects, it is now greatly superior to a lot of Windows applications. And it is Free Software, with sources!

It will now help you to check your old rips against the AccurateRip database, but it was already annouced two weeks ago or so. However, tmkk has gone _far_ further :

- XLD can now check the accuracy of files, like ARCue does. But ARCue was slow (in its Perl implementation) or Windows-only (in its C++ implementation) and needed the input file to be a .wav (one had to decompress his compressed file, change the cue to link it to the new .wav). XLD uses native code, and is able to check from a .cue/[.flac|.wv|.ape] and a few more obscure ones, like the ill-fated Apple Lossless.

- For those of you who know TripleFlac, it is a Windows utility that can find if the inaccuracy of a file is only an offset problem. As it is the case in the majority of rips (they are good but there is an offset problem), we can say that it really improves AccurateRip's concept. In seconds, its algorithm checks hundreds of offset variation and when a checksum matches, it adds it to the list of every offset found in the DB with their respective confidence.

- And finally, icing on the cake, it can, like CUETools on Windows, re-offset the file so that it is "repaired" and is the same than the Golden Master CD.

All of that happens in one only software, in a very short period of time: one checks the offset, then the accurateness of the rip according to AccurateRip's DB. The software then offer to re-offset it and to save it in the lossless format of your choice (may I suggest FLAC ? )


XLD v86.1

XLD did it again!

Reply #1 –
Quote from: Saxo on
- And finally, icing on the cake, it can, like CUETools on Windows, re-offset the file so that it is "repaired" and is the same than the Golden Master CD.


I've been slowly writing code to do something like this for the past few months.  I started by converting arcue.pl to C code.  Then I wrote it in a way that you could pipe in the output of "flac -sdc" so I didn't have to decode to a wav file first.  My next task in progress was to start searching positive and negative offsets on the shortest track (and then the next shortest in case the shortest actually contained an error).

XLD accomplishes this far quicker than my existing code.  Even the flac checking seems quicker than my STDOUT flac decode.

This is an amazing gift this morning.  I foresee a donation in the future.

XLD did it again!

Reply #2 –
That's amazing!

Every day brings a new gift from the XLD gods.

XLD did it again!

Reply #3 –
Quote from: fracai on
This is an amazing gift this morning.  I foresee a donation in the future.

I foresee a donation tomorrow in the morning. I asked some changes related to post-processing files with AccurateRip to tmkk two days ago and SIX hours later XLD had a working prototype of offset correction. The next day, I asked a system to change the offset to fix the wrongly offset files. I don't think it even took six hours.

This guy is amazing, as an human being as well as a genious programmer.

XLD did it again!

Reply #4 –
I'm going to ask him to do something about the heat in Texas.

I know, OT, but since he has been so receptive, even to some things he's not in favor of (e.g. wording of log re: AR mismatches/inconsistencies), I figure it's worth a shot (and another donation).

XLD did it again!

Reply #5 –
Almost scary pace of development.
Soon this software might be able to read our minds!

Really - every day is like Christmas with this program.

XLD did it again!

Reply #6 –
This is the first time I have ever donated to a freeware/shareware program.  What an awesome development for us long-suffering Mac users.

XLD did it again!

Reply #7 –
Accurate ripping was the last thing constantly pulling me back to XP after switching to my Mac a year ago.

A million thanks to the XLD developer and for freeing me from Windows!
- FLAC/200GB external
- AAC 128 vbr/local
- iPod Nano 2G 8GB

XLD did it again!

Reply #8 –
Where's the Windows port?

XLD did it again!

Reply #9 –
I've been trying to find developers to handle this with Windows but have had no luck.  Everyone's been too busy.  What's left is checking rips from enhanced discs against the database and I've figured out a good way to do this as well.  If I could program, things would be different.  Oh well...

XLD did it again!

Reply #10 –
Quote from: greynol on
I've been trying to find developers to handle this with Windows but have had no luck.

The first thing to know is whether tmkk is interested in a Windows port of XLD.

XLD is very modular and only a part of it is Mac only (the interface part uses NS classes, but the real power of XLD lies in its engine). If I'm not mistaken, tmkk uses Objective-C structures in a very conservative fashion (minimal use of NS classes, which mostly encapsulate C code), which should easy the process of rewriting the Objective-C parts in C for a Windows version. It also relies on various libraries available for Windows (libflac, ape's lib, wavepack's lib, for instance).

If tmkk is interested in blessing the Dark Side (or those who are forced to work with the Dark Side) by its software, knowing that the demand is huge, all he has to do is open a Sourceforge/BerliOS/GoogleForge for XLD and let the developers come. Free software has this advantage that if a project is interesting, it _will_ attract developers.

The only think that will slow the process is that tmkk is a person with a really good memory and it has the drawback that his code is barely commented.

Greynol, you seem to have information on what tmkk thinks about it. Is he aware of this topic? If not, we should invite him.

Cheers,
Stéphane

XLD did it again!

Reply #11 –
Quote from: CPL593H on
The first thing to know is whether tmkk is interested in a Windows port of XLD.
I'm not really sure how to respond to this suggestion other than to say I'd like it to be incorporated into dBpoweramp or EAC as a ripping strategy (although AR2 is around the corner, though it will have its drawbacks if it means that data from beginning and ending frames will be discarded, but AR2's checksum will be more robust as the current one isn't a real CRC).  Another option is to have tripleflac improved or have the checking portion of XLD as an independent tool.  The bottom line is that cdparanoia doesn't quite measure up to methods implemented by dBpoweramp and EAC (but to a lesser degree) with drives that provide C2 error information (ignoring the uncertainty surrounding cache handling).

Quote from: CPL593H on
Is he aware of this topic?
I'm pretty sure he is.  I'm not aware of what's going on in other forums, but it seems that he's been incredibly responsive to the comments being posted here.
 

XLD did it again!

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

XLD did it again!

Reply #13 –
Quote from: spoon on
if 2000 offsets are tested then the 1:4 billion collision is 1:4 billion / 2000)

Looks like an acceptable risk to me when you compare it to the advantages (ie. if I ripped a disc with a bad offset two years ago, without offset adjustments, I have no way to know if it is accurate or not – and it means 'trash' and 'empty trash' to me). Statistically, it would matter if it was secret defense documents. Now, if one bit of Bryan Ferry would suffer, I can accept the risk.

XLD did it again!

Reply #14 –
Quote from: spoon on
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).


I don't understand the problem since we can run a AccurateRip check on the corrected file just after the offset detection to check the who CD? I just ask, I don't get it

XLD did it again!

Reply #15 –
Quote from: CPL593H on
Now, if one bit of Bryan Ferry would suffer, I can accept the risk.

As long as it's not his vocal cords, eh.

XLD did it again!

Reply #16 –
Not to get to deeply into it, but it's already been demonstrated that the chances of collision are greater than originally anticipated since every 65536th sample is not figured into the checksum calculation.

I'm not sure if XLD is set up to be able to do a different offset for every track (I hope not).  My method has always been to apply a consistent offset and rip (and yes, I rip with an offset corrected for AR, I don't use tripleflac or arcue).  The reason I think a consistent offset is better is that it will likely catch discs where one track gives repeated samples resulting in the remaining tracks being ripped that number of samples early ("broken accurate stream").  Of course there is the possibility that a pressing in the database has suffered from broken accurate stream, as this can be consistent due to manufacturing defect and can behave consistently when ripped with drives with the same chipset.  Perhaps checking with a different pressing, or noting which tracks required a different offset.

XLD did it again!

Reply #17 –
XLD should now be able to check your disc against alternate pressings while ripping.

Anyone want to try this feature out and report back?

XLD did it again!

Reply #18 –
Quote from: greynol on
XLD should now be able to check your disc against alternate pressings while ripping.

Anyone want to try this feature out and report back?


I'm curious: does this type of feature increase the AR server load, or is it implemented entirely in the client using the initial data downloaded from the AR servers?

-brendan

XLD did it again!

Reply #20 –
Why is the check offset in the ripping stage not available for the first and the last track?  I believe that this feature is automaticly implemented during the ripping process because I can not find anything in the preference menu or the application menu bar any where.  I ripped a CD today with Version 20080908 and found a entry called List of suggested offset correction values in the log report.  See report log below.

Code: [Select]
X Lossless Decoder version 20080908 (87.0)

XLD extraction logfile from 2008-09-08 05:20:40 -0400

Van Halen / Women And Children First

Used drive : HP CD-Writer+ 7500 (revision 1.0a)

Use cdparanoia mode    : YES
Disable audio cache    : YES
Read offset correction : 1160
Max retry count        : 100

TOC of the extracted CD
     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  | 00:00:33 | 03:33:20 |        33    |    16027   
        2  | 03:33:53 | 05:08:40 |     16028    |    39167   
        3  | 08:42:18 | 05:56:57 |     39168    |    65924   
        4  | 14:39:00 | 04:19:50 |     65925    |    85399   
        5  | 18:58:50 | 00:56:50 |     85400    |    89649   
        6  | 19:55:25 | 02:39:10 |     89650    |   101584   
        7  | 22:34:35 | 03:11:53 |    101585    |   115962   
        8  | 25:46:13 | 03:09:35 |    115963    |   130172   
        9  | 28:55:48 | 04:40:40 |    130173    |   151212   

List of suggested offset correction values
    (1) -1685 (confidence 13)
    (2) -104 (confidence 5)
    (3) 558 (confidence 4)

All Tracks
    Filename : /Users/macman4hire/Desktop/Women And Children First.flac
    CRC32 hash             : 97215CF6
    CRC32 hash (skip zero) : 192FD21E
    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 01
    CRC32 hash             : 91532BBA
    CRC32 hash (skip zero) : EBF45792
    AccurateRip signature  : D56969FF
        ->Accurately ripped! (confidence 8)
    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
    CRC32 hash             : 43821650
    CRC32 hash (skip zero) : DDEC81DC
    AccurateRip signature  : D04019C4
        ->Accurately ripped! (confidence 9)
    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
    CRC32 hash             : FA9489B3
    CRC32 hash (skip zero) : 3E4C3B6F
    AccurateRip signature  : 0670EF04
        ->Accurately ripped! (confidence 8)
    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
    CRC32 hash             : 9DA741B7
    CRC32 hash (skip zero) : 62D398BB
    AccurateRip signature  : 3B54346E
        ->Accurately ripped! (confidence 9)
    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
    CRC32 hash             : 0FB64F4D
    CRC32 hash (skip zero) : B0E436D6
    AccurateRip signature  : 0685A815
        ->Accurately ripped! (confidence 8)
    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
    CRC32 hash             : 073E2695
    CRC32 hash (skip zero) : C5CDC3F4
    AccurateRip signature  : 21CABFB2
        ->Accurately ripped! (confidence 8)
    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
    CRC32 hash             : 9ACEA20E
    CRC32 hash (skip zero) : 1EF0A9F2
    AccurateRip signature  : 363993C4
        ->Accurately ripped! (confidence 8)
    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
    CRC32 hash             : 274EBA47
    CRC32 hash (skip zero) : 3156C48A
    AccurateRip signature  : 567A21E4
        ->Accurately ripped! (confidence 7)
    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
    CRC32 hash             : B604DF3C
    CRC32 hash (skip zero) : 70F408DA
    AccurateRip signature  : B3F78E1B
        ->Accurately ripped! (confidence 8)
    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

XLD did it again!

Reply #22 –
Quote from: greynol on
There's doesn't seem to be anything wrong based on your log file.

I don't believe that anything is wrong.  Just wondering about what was stated In the update documentation: 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.  My question is why does it not check the first and last tracks and does it need to for any reason?

XLD did it again!

Reply #23 –
I must admit that I am totally confused over what exactly the "list of suggested offset correction values" means.

Here's a rip I just did. The rip itself checks out, and the suggested offset correction value is 871. But when and why would you use the 871 offset??

Code: [Select]
X Lossless Decoder version 20080911 (87.3)

XLD extraction logfile from 2008-09-10 20:07:11 -0500

Can / Tago Mago

Used drive : PIONEER DVD-RW  DVR-108 (revision 1.17)

Use cdparanoia mode	: YES
Disable audio cache	: YES
Read offset correction : 48
Max retry count		: 100

TOC of the extracted CD
	 Track |   Start  |  Length  | Start sector | End sector 
	---------------------------------------------------------
		1  | 00:00:32 | 07:28:00 |		32	|	33631   
		2  | 07:28:32 | 04:03:03 |	 33632	|	51859   
		3  | 11:31:35 | 07:24:37 |	 51860	|	85196   
		4  | 18:55:72 | 18:28:10 |	 85197	|   168306   
		5  | 37:24:07 | 17:33:38 |	168307	|   247319   
		6  | 54:57:45 | 11:38:02 |	247320	|   299671   
		7  | 66:35:47 | 06:45:73 |	299672	|   330119   

List of suggested offset correction values
	(1) 871 (confidence 10)

Track 01
	Filename : /Users/x/Desktop/Can - Tago Mago/01 - Paperhouse(1).flac

	CRC32 hash (test run)  : 1ADEFF0C
	CRC32 hash			 : 1ADEFF0C
	CRC32 hash (skip zero) : E7E7924C
	AccurateRip signature  : B222CBBD
		->Accurately ripped! (confidence 10)
	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/x/Desktop/Can - Tago Mago/02 - Mushroom(1).flac

	CRC32 hash (test run)  : CBE7CD2E
	CRC32 hash			 : CBE7CD2E
	CRC32 hash (skip zero) : 5E237342
	AccurateRip signature  : C02D63BD
		->Accurately ripped! (confidence 10)
	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/x/Desktop/Can - Tago Mago/03 - Oh Yeah.flac

	CRC32 hash (test run)  : DAE43DCF
	CRC32 hash			 : DAE43DCF
	CRC32 hash (skip zero) : 06EE8AED
	AccurateRip signature  : 128C51DC
		->Accurately ripped! (confidence 11)
	Statistics
		Read error						   : 0
		Skipped (treated as error)		   : 0
		Edge jitter error (maybe fixed)	  : 2
		Atom jitter error (maybe fixed)	  : 1
		Drift error (maybe fixed)			: 0
		Dropped bytes error (maybe fixed)	: 1
		Duplicated bytes error (maybe fixed) : 1
		Inconsistency in error sectors	   : 0

Track 04
	Filename : /Users/x/Desktop/Can - Tago Mago/04 - Halleluhwah.flac

	CRC32 hash (test run)  : 3225FEBC
	CRC32 hash			 : 3225FEBC
	CRC32 hash (skip zero) : 0659F2FE
	AccurateRip signature  : 3FC649A4
		->Accurately ripped! (confidence 10)
	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/x/Desktop/Can - Tago Mago/05 - Aumgn.flac

	CRC32 hash (test run)  : 42BA58B7
	CRC32 hash			 : 42BA58B7
	CRC32 hash (skip zero) : A0588DE6
	AccurateRip signature  : FF895D23
		->Accurately ripped! (confidence 10)
	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/x/Desktop/Can - Tago Mago/06 - Peking O.flac

	CRC32 hash (test run)  : E1D5B39F
	CRC32 hash			 : E1D5B39F
	CRC32 hash (skip zero) : 939B1844
	AccurateRip signature  : FB6B0DD1
		->Accurately ripped! (confidence 8)
	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) : 0
		Inconsistency in error sectors	   : 0

Track 07
	Filename : /Users/x/Desktop/Can - Tago Mago/07 - Bring Me Coffee Or Tea.flac

	CRC32 hash (test run)  : 74CF3981
	CRC32 hash			 : 74CF3981
	CRC32 hash (skip zero) : 19DC8942
	AccurateRip signature  : BF75ABF6
		->Accurately ripped! (confidence 9)
	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
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Moderation: Code changed to codebox.  Please use codebox for all future log postings.[/size]

XLD did it again!

Reply #24 –
This rip I did has three suggested offset correction values listed.  I am not sure what this means either.  I looked for (1) -1685 (confidence 13) on the AccurateRip offset correction webpage and could not find any drives with that correction.  Interesting!  Check log below.
Code: [Select]
X Lossless Decoder version 20080908 (87.0)

XLD extraction logfile from 2008-09-08 05:20:40 -0400

Van Halen / Women And Children First

Used drive : HP CD-Writer+ 7500 (revision 1.0a)

Use cdparanoia mode    : YES
Disable audio cache    : YES
Read offset correction : 1160
Max retry count        : 100

TOC of the extracted CD
     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  | 00:00:33 | 03:33:20 |        33    |    16027   
        2  | 03:33:53 | 05:08:40 |     16028    |    39167   
        3  | 08:42:18 | 05:56:57 |     39168    |    65924   
        4  | 14:39:00 | 04:19:50 |     65925    |    85399   
        5  | 18:58:50 | 00:56:50 |     85400    |    89649   
        6  | 19:55:25 | 02:39:10 |     89650    |   101584   
        7  | 22:34:35 | 03:11:53 |    101585    |   115962   
        8  | 25:46:13 | 03:09:35 |    115963    |   130172   
        9  | 28:55:48 | 04:40:40 |    130173    |   151212   

List of suggested offset correction values
    (1) -1685 (confidence 13)
    (2) -104 (confidence 5)
    (3) 558 (confidence 4)

All Tracks
    Filename : /Users/macman4hire/Desktop/Women And Children First.flac
    CRC32 hash             : 97215CF6
    CRC32 hash (skip zero) : 192FD21E
    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 01
    CRC32 hash             : 91532BBA
    CRC32 hash (skip zero) : EBF45792
    AccurateRip signature  : D56969FF
        ->Accurately ripped! (confidence 8)
    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
    CRC32 hash             : 43821650
    CRC32 hash (skip zero) : DDEC81DC
    AccurateRip signature  : D04019C4
        ->Accurately ripped! (confidence 9)
    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
    CRC32 hash             : FA9489B3
    CRC32 hash (skip zero) : 3E4C3B6F
    AccurateRip signature  : 0670EF04
        ->Accurately ripped! (confidence 8)
    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
    CRC32 hash             : 9DA741B7
    CRC32 hash (skip zero) : 62D398BB
    AccurateRip signature  : 3B54346E
        ->Accurately ripped! (confidence 9)
    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
    CRC32 hash             : 0FB64F4D
    CRC32 hash (skip zero) : B0E436D6
    AccurateRip signature  : 0685A815
        ->Accurately ripped! (confidence 8)
    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
    CRC32 hash             : 073E2695
    CRC32 hash (skip zero) : C5CDC3F4
    AccurateRip signature  : 21CABFB2
        ->Accurately ripped! (confidence 8)
    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
    CRC32 hash             : 9ACEA20E
    CRC32 hash (skip zero) : 1EF0A9F2
    AccurateRip signature  : 363993C4
        ->Accurately ripped! (confidence 8)
    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
    CRC32 hash             : 274EBA47
    CRC32 hash (skip zero) : 3156C48A
    AccurateRip signature  : 567A21E4
        ->Accurately ripped! (confidence 7)
    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
    CRC32 hash             : B604DF3C
    CRC32 hash (skip zero) : 70F408DA
    AccurateRip signature  : B3F78E1B
        ->Accurately ripped! (confidence 8)
    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
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Moderation: Removed unnecessary quotation.[/size]