CUETools DB Options

[korth]

CT was then able to recognize the disc, but still wouldn't do a repair.

The recovery record can only repair a limited amount of damage. Your rip likely exceeds that amount of damage.

This post has been edited by korth: Dec 30 2012, 15:32

[Eli]

CT was then able to recognize the disc, but still wouldn't do a repair.

The recovery record can only repair a limited amount of damage. Your rip likely exceeds that amount of damage.

Korth, you are probably right. I wish CT would tell you something to that effect...

[lvqcl]

http://www.cuetools.net/wiki/CUETools_log

Accurately ripped -- Your rip matches database records for this track
Differs in ... -- Partial match this track, might be repairable
No match -- Too many samples differ

[ebz777]

Add Chromaprint and AcoustID relationships within CUETools DB

Hello Gregory,
The CUETools DB is already cross-referencing at the CD TOC level the freedb and MusicBrainz databases.
Would you also consider doing this at the tracklevel with Chromaprint fingerprints and AcoustIDs (see http://acoustid.org/) ?

This would help the match of an individual track to a release, regardless of any later lossy re-encoding. This is something you cannot do with the current CUETools DB tracks CRCs alone : there is now way to calculate that proper CRC for an mp3 track for example. The only way to ensure a consistent fingerprint calculation for a CD release is at ripping time.

It would require to calculate the chromaprint fingerprint for every tracked ripped with CUERipper and add these references to CUETtools DB.
I'm not sure though that CUETools DB should also link the AcoustID; the fingerprint -> AcoustID assignment process is still very far from perfect (see http://forums.musicbrainz.org/viewtopic.php?id=3869). But it could be considered safe, there is no plan to merge AcoustID I believe and it would be a nice bonus !

Maybe CUERipper/CUETools could then also publish the calculated Chromaprint fingerprints to the AcoustID DB (see http://acoustid.org/webservice#submit)

Additionally CUETools could then also tag the tracks it generates with the AcoustID

Thanks

[bilbo]

Add Chromaprint and AcoustID relationships within CUETools DB
This would help the match of an individual track to a release, regardless of any later lossy re-encoding.

CUEToolsDB is meant to verify and/or repair rips from a CD. Why would anyone want to verify a "lossy" track? That is the opposite of what the DB was designed to accomplish.

[ebz777]

CUEToolsDB is meant to verify and/or repair rips from a CD. Why would anyone want to verify a "lossy" track?

Yes, the data correction made ​​during a rip is what motivates a large number of users to publish their information in the database in the first place. But once the information is out there it is metadata that can be used for purposes that were not originally intended. Eg to identify similar recordings from different releases, to find out what recordings exactly are included in a compilation. To identify whether a particular release includes the original or remastered version of a recording. Or in the presence of a piece of music lossy you want to tag, to know what CD this song was coming from.

This is something that you cannot do with the track CRC calculated today, but that you could do if you add a fingerprint calculation to the track.

It's of course best calculated at rip time since it's the surest way to ensure consistency between a CD and its track information.

[Gregory S. Chudo...]

It doesn't seem very fair - people that would be wasting their CPU cycles to calculate those fingerprints would be helping a completely different category of users to identify random mp3s.