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 !

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.

When ripping a disc with short silent pregaps, AccurateRip says it's ok, but CUETools DB always say some samples differ. So I try to repair it with CUETools, but nothing happens, and CUETools' output log determines it's accurate on CUETools DB.

Should I be concerned with this or is this normal behaviour? BTW, my CD drive can't read pregaps.

Here is the EAC log of Suzanne Vega's S/T. Note the CUETools DB section of the log says some samples differ.

[CTDB TOCID: Qg0b_gWtEeWHdK7xH1oZi2f.i_Q-] found, Submit result: discs with pregaps not supported in this protocol version[e7389015] (359/359) Differs in 10921 samples @00:00:35-00:00:50You can use CUETools to repair this rip.

[CTDB TOCID: Z05mxINrbJ8ZVnge2ceC6GJBBec-] found, Submit result: discs with pregaps not supported in this protocol version[a8d49654] (103/104) Differs in 5708 samples @00:00:20-00:00:25[5362c05c] (001/104) No matchYou can use CUETools to repair this rip.

Donīt know if I understand this log correctly.CTDBID: what do the lines 4 and 5 with a comma mean? Rips with extra data track, I suppose?ARID: how to interprete these? All submissions without extra data track?

The wiki has a link to the database web page. I didn't plan to add documentation of this type to the wiki but I can. I'm so far behind updating pages already though.Search by 'tocid' using db.cuetools.net/?tocid=Search by 'artist' (most recent first) using db.cuetools.net/?artist=Search by 'artist' (most popular first) using db.cuetools.net/top.php?artist=of course you need to fill in missing data after the '=' such as db.cuetools.net/top.php?artist=adele

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.

It is not for random mp3s actually. When I buy a compilation and when I rip it, I like to know to which original album releases the tracks correspond. Then I like also to be able to deconstruct that compilation and tag each individual tracks with the meta data of the original album releases, with a high certainty that these are the right albums.

Today I cannot do these if I donít also own the albums, because it is often not possible to find out that information through the compilation liner notes and CUETools DB track CRCs are no help because they are two precise. If tomorrow CUETools DB contained the AcoustID of all tracks, we could determine which tracks we are actually buying and ripping.

It's quite fast to calculate an AcoustID, but I understand that some persons, sensitive to the time their rip takes or to the number of CPU cycles are opposed to calculate and publish them. However this concern could be overcome by providing this calculation as an option. That way, those persons could keep the option disabled. This should not be a problem for the database. It is sufficient after all if for each Disc Id just one person is motivated enough to calculate the AcoustID once in order to have that information available in the database attached to every track.

There are already several programs out there that use the MusicBainz database to identify tracks. Picard is one of them. They put the acoustic id in the tags and give you all the tag info. IIRC, MP3Tag also uses MusicBainz for retrieving tags. Have you tried this route? If there are programs that do what you want, why reinvent the wheel here?

There are already several programs out there that use the MusicBainz database to identify tracks. Picard is one of them. They put the acoustic id in the tags and give you all the tag info. IIRC, MP3Tag also uses MusicBainz for retrieving tags. Have you tried this route? If there are programs that do what you want, why reinvent the wheel here?

Iím using MusicBrainz/AcoustID through Picard and Jaikoz. Unfortunately fingerprints in acoustid.org are linked to recordings in MusicBrainz not to Disc IDs. MusicBrainz/AcoustID rely on these current tagging softwares to calculate the fingerprints and associate them to recordings. Since these software work at the track level and not the disc level they have no better option.

And these tagging softwares canít also force any particular workflow. So you end up having users tagging a bunch of mp3ís and polluting the database by associating them with the wrong recordings. In the end itís a useless mess for the purpose I was describing.

Only a special ripping software like Cuetools could calculate a fingerprint for each track and ensure that they are associated together properly with a unique Disc ID.