CUETools DB Options

[greynol]

[...] dBpoweramp's ACCURATEDISCID [...] Despite the name, that is the track ID.

<nitpick>This is correct, though I think it's a bit misleading since only an enumeration is appended in order to differentiate tracks within the record which itself is named from the disc ID. That this enumeration is actually part of the disc ID is definitely debatable, IMO.</nitpick>

This post has been edited by greynol: Jul 4 2011, 01:09

[Gregory S. Chudo...]

Gregory, would you consider adding support for the CDTOC in meta-data. To many of my discs are not recognized when I try to verify and submit. I have over 5000 securely ripped CDs that I would like to submit to the DB.

Thanks for the info, this would help with pregap/data track issues, and the tag format seems sensible enough.

[Porcus]

Gregory, would you consider adding support for the CDTOC in meta-data. To many of my discs are not recognized when I try to verify and submit. I have over 5000 securely ripped CDs that I would like to submit to the DB.

Thanks for the info, this would help with pregap/data track issues, and the tag format seems sensible enough.

I second Eli's wish here. Including the '5000' figure for the database

And to quote myself:

... and maybe even dBpoweramp's ACCURATEDISCID tag too? Despite the name, that is the track ID.

That would not aid the database, but would make possible single-file verification. (@Greynol: Yeah, but you missed my point: the tag identifies the track and not only the disc.)

This post has been edited by Porcus: Aug 8 2011, 17:45

[zfox]

I noticed that I can increase the confidence number of a disc (stored in CTDB) by ripping it again and again with CUERipper using the same OS instalation. Should there be a protection mechanism to avoid that case? Spoon scrutinizes submissions just to keep his DB clean and credible. I think this paradigm can be applied to CTDB as well.

I am not sure if this issue was discussed before for CTDB.

This post has been edited by db1989: Oct 1 2011, 14:16

Reason for edit: CDDB -> CTDB, by request

[Gregory S. Chudo...]

As i mentioned in another thread, right now confidence levels are a bit of a mess, because they combine past measurements of AR confidence levels with the number of direct CTDB submissions since that point.

In the near future, i plan to reset CTDB confidence levels to the actual number of independent submissions.

For now, i suggest to use CTDB as a source of repair material, not as verification of rip accuracy in itself.

[mjb2006]

For now, i suggest to use CTDB as a source of repair material, not as verification of rip accuracy in itself.

Hmm, but I've found that when CTDB has a record for an error-containing rip, CUETools won't let that rip be repaired against any other CTDB submission.

For example, I have a scratched disc that I ripped with CUERipper in burst mode. Despite containing errors on 2 tracks, it was apparently submitted to CTDB. I thought it would be no problem; eventually someone would make a CTDB submission for a clean rip, and then I could correct mine against it. It does seem that there's now such a submission, but CUETools won't repair my rip against it, because it's finding the bad rip in CTDB:

Results for an Encode/repair action:

CODE

.\Various Artists - I-Robots_ Italo Electro Disco Underground Classics.flac: verified OK, confidence 1.

Results for a Verify/default action (edited to show just the CTDB part):

CODE

[CTDB TOCID: Ta8fLh3t.nOoXGvbbGehaUIiH64-] found.
        [ CTDBID ] Status
        [3bd0e182] (1/7) Accurately ripped
        [cce5f891] (5/7) No match
        [90a84fca] (1/7) No match

I assume if I re-rip, the errors will be different, and I'll be given the choice of correcting to match one of the three CTDB submissions (cce5f891 seems to be the one I want). I really wish I could just use my broken rip, though. Isn't that the ideal circumstance—keeping your bad rips around until they're repairable?

[sauvage78]

Before I forget, if you want you can delete any entry under [CTDB TOCID: VTlxZK5YWAOpfUBqTTA67jhHTTM-], it's me playing with a scratched french Christmas songs CD, the submissions are obviously bad (hearable glitch). It would be nice if the EAC plugin would not automatically upload Secure rip with errors, unless you can verify if those are AR(2) despite errors which is unlikely (but far from impossible with bad EAC settings). The CTDB size has exploded since the introduction of the EAC plugin but without this filter I fear that there is a lot of scratched data (like mine) uploaded ... even if you shouldn't fix stuff without listening to what you fix & even if you should verify that it's AR(2) after fixing ... it would be better to filter crap from start to avoid an uncontrolled inflation of the database.

This post has been edited by sauvage78: Dec 27 2011, 19:51

[Gregory S. Chudo...]

Hmm, but I've found that when CTDB has a record for an error-containing rip, CUETools won't let that rip be repaired against any other CTDB submission.

According to the log, the supposedly "good" rip is listed as "No match", that just means that your rip had too many errors to be correctable. If it was correctable, you would see the list of error locations instead of "No match", and CUETools would offer you to repair using this entry.

it would be better to filter crap from start to avoid an uncontrolled inflation of the database.

I can always clean it up later Database isn't yet that large. But i'm still slowly improving filters, it just wasn't a priority.

Beta-testing CTDB 2.0 with new version of EAC plugin:
https://plus.google.com/b/10448316314704930...sts/HthUiJ7ZSwz

[Pepzhez]

Now that the CTDB is ignoring pregaps, I just discovered that if I rip a disc that has pregaps with CUERipper, the database will no longer accept the submission. Unfortunately there is no option in CUERipper to ignore HTOA, so six of the ten discs I ripped today will not be in the database, even though all of them were AR confirmed with confidence levels of 3 or higher.

When will an update of CUERipper that includes an option to rip without HTOA be coming?

This post has been edited by Pepzhez: Jan 25 2012, 04:36

[Eli]

Looks like spoon/dbpoweramp plans to implement a separate but similar system to CTDB:

http://forum.dbpoweramp.com/showthread.php...ll=1#post120964

[Gregory S. Chudo...]

Thanks, i've heard. I rather hoped we could cooperate on this, because IMHO having two separate databases is bit counterproductive. But let's see how it works.

By the way, CTDB recently reached an important mark - 1M rips and 0.5M discs.

[Eli]

Gregory, would you consider adding support for the CDTOC in meta-data. To many of my discs are not recognized when I try to verify and submit. I have over 5000 securely ripped CDs that I would like to submit to the DB.

Thanks for the info, this would help with pregap/data track issues, and the tag format seems sensible enough.

Gregory,
Where does this stand?

[drfsupercenter]

Hey guys

I like using FLACCL with CUERipper, however, since switching from a NVIDIA to an AMD card, it no longer works. If I use command-line FLACCL, I can tell it to use the CPU instead of the GPU... does CUERipper have any way to tell it to do the same? It provides better compression than the other methods (as far as I can tell), so it's a bit disappointing that I can't get it to work.

[korth]

This might get better response in the FLACCL thread.
I know you can change GPU/CPU on the Encoder tab in CUETools Advanced Settings but without the hardware to test it I don't know if the settings carry over to CUERipper. I don't see anything in %appdata%\CUERipper\settings.txt to change it.

[korth]

I guess I could have also told you how to add the FLACCL exe to CUERipper (if needed).

Close CUERipper and make backup of %appdata%\CUERipper\settings.txt
Edit %appdata%\CUERipper\settings.txt
Search for ExternalEncoders=
Above that line, add the following (replacing ## with the next number in sequence and exclude all the Red notations.

ExternalEncoder##Name=FLACCL cmd
ExternalEncoder##Modes=0 1 2 3 4 5 6 7 8 9 10 11 (Mode selection values - shown on slider)
ExternalEncoder##Mode=8 (Default selected mode)
ExternalEncoder##Extension=flac
ExternalEncoder##Path=CUETools.FLACCL.cmd.exe (Full path not required if exe is in CUETools folder)
ExternalEncoder##Lossless=1
ExternalEncoder##Parameters=-%M - -o %O (Placeholders %M = mode, - = input, and %O = output are required. You'll need to add the other parameters as needed for your hardware)

You then need to add 1 to the number of external encoders (if it was 19, then it would become 20).
ExternalEncoders=20
and save file.

[drfsupercenter]

Got another question regarding CUERipper.

I notice, in the newest build (2.1.4), whenever I select CBR (libmp3lame) to do rips of a CD, it automatically inserts its own advertising in the "Comments" tag of the mp3. Specifically, "CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov"

Can I disable that? It's incredibly annoying and one reason I started using CueRipper INSTEAD of other software was because it didn't force advertisements in my music. I'd happily go back to 2.1.2a just to get rid of the comment spam, but I thought I would ask on here.

I looked through all the options and couldn't find anything at all pertaining to how files are tagged...

--EDIT--

It does it for FLAC too. Looks like any of my rips are tainted with the ad.

This post has been edited by drfsupercenter: Oct 11 2012, 02:29

[korth]

The version info is only inserted when the Comment field is blank. There is currently no way in 2.1.4 to disable other than adding some text to the Comment field.

[Porcus]

This is hardly the right thread anyway, but: can't one just remove all such lines afterwards?

[drfsupercenter]

Well that's disappointing. I guess I'm going back to 2.12a, I don't want advertisements in my files...

@Porcus, what?

[Porcus]

@Porcus, what?

This thread is for the database that verifies your rips. The thread for CUETools is at http://www.hydrogenaudio.org/forums/index....showtopic=66233 .

By the way, couldn't you just remove that line from every cuesheet (in batch I mean, not one manually one at the time)?

[frozenspeed]

Well that's disappointing. I guess I'm going back to 2.12a, I don't want advertisements in my files...

What do you do about all the label, distribution & production advertisements on your cds?

[drfsupercenter]

Well that's disappointing. I guess I'm going back to 2.12a, I don't want advertisements in my files...

What do you do about all the label, distribution & production advertisements on your cds?

I don't include those when ripping the files, obviously.

This thread is for the database that verifies your rips. The thread for CUETools is at http://www.hydrogenaudio.org/forums/index....showtopic=66233 .

By the way, couldn't you just remove that line from every cuesheet (in batch I mean, not one manually one at the time)

Ah. I didn't realize that, I saw Cuetools and didn't know the DB was something separate. My bad.

Also, these tags are not in the cuesheet but in the actual files themselves, so that solution won't work :/

[ebz777]

Pb with recent Musicbrainz releases + CD toc, not found in CUETools DB

I encounter the following problem : when I'm adding a new release in MusicBrainz, attach the CD TOC to the release and then try to rip it, CUEripper doesn't find the MusicBrainz release. When I check CUETools DB, I can see that it is not in the DB either. This use to work.

Ex 1:
http://db.cuetools.net/top.php?artist=Carmen%20Miranda
select Carmen Miranda - Brazilian Recordings
If you look at the bottom of the page, in the CUETools DB album list section, it has only a single freedb album, but no MusicBrainz one.
But if you follow the MusicBrainz CD lookup you on that page you can see that a release actually exist for this CD TOC in MusicBrainz.

Ex 2:
http://db.cuetools.net/top.php?artist=George%20Harisson
select George Harrison - All Things Must Pass
you can see that there a only 2 MusicBrainz releases (US and GB) in the album section
If you follow the MusicBrainz CD lookup for that TOC you can see that there is a third one.
The latest one recently added (2001, country XE) is not there.

and so on ...

I know that CTDB replicates MusicBrainz database hourly,
but I've be waiting for several days now and nothing happened.

What is the problem ?
Thanks in advance for your help.

[Gregory S. Chudo...]

Musicbrainz recently released a new schema which required an upgrade to postgresql 9. I'm working on it.

[Eli]

I know this disc is in the CTDB, but I can't seem to get CT to do a repair. I have ripped with dbpoweramp. CTDB wouldn't recognize, so I re-ripped with CueRipper, which can't rip the last track. Tried in burst mode, but its still doing tons of error correction and gets stuck. Tried with EAC and it can't rip the track either (can't seem to find burst mode in the latest EAC with CTDB support).

Created a CUE with Cueripper and transferred the CUE and 00 - HTOA track to the dbpoweramp directory. CT was then able to recognize the disc, but still wouldn't do a repair.

CODE

[CUETools log; Date: 12/29/2012 5:05:10 PM; Version: 2.1.4]
[CTDB TOCID: ujvjyuIIqdR61HbcM3huXrxTUi8-] found.
Track | CTDB Status
  1   | (5/6) Accurately ripped
  2   | (5/6) Accurately ripped
  3   | (5/6) Accurately ripped
  4   | (5/6) Accurately ripped
  5   | (5/6) Accurately ripped
  6   | (5/6) Accurately ripped
  7   | (5/6) Accurately ripped
  8   | (5/6) Accurately ripped
  9   | (5/6) Accurately ripped
10   | (5/6) Accurately ripped
11   | (5/6) Accurately ripped
12   | (0/6) No match
[AccurateRip ID: 0018635f-00e3861c-930dc30c] found.
Track   [  CRC   |   V2   ] Status
01     [60bf57fe|22355748] (0+0/2) No match
02     [d4f00ec3|d7e586cb] (0+0/2) No match
03     [27877b37|c51e2f72] (0+0/2) No match
04     [4b27f567|e978299e] (0+0/2) No match
05     [9b76c989|857c20a6] (0+0/2) No match
06     [86e676e1|7211ae70] (0+0/2) No match
07     [1afb75c3|e2016a78] (0+0/2) No match
08     [f3503b15|3312270a] (0+0/2) No match
09     [e685750c|91e482e0] (0+0/2) No match
10     [5ed89126|cb73314f] (0+0/2) No match
11     [ac39c742|ffd92e9d] (0+0/2) No match
12     [8126c2c7|919d503c] (0+0/2) No match
Offsetted by 6:
01     [dc5ca8d0] (2/2) Accurately ripped
02     [f7492949] (2/2) Accurately ripped
03     [65ca5a8f] (2/2) Accurately ripped
04     [0a47b8cb] (2/2) Accurately ripped
05     [6e6cf5e3] (2/2) Accurately ripped
06     [787a66a3] (2/2) Accurately ripped
07     [1f853ad7] (2/2) Accurately ripped
08     [7aa64579] (2/2) Accurately ripped
09     [22337ad0] (2/2) Accurately ripped
10     [a1f8324a] (2/2) Accurately ripped
11     [5d24e404] (2/2) Accurately ripped
12     [fc192947] (0/2) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL]
--  100.0 [AA03330F] [90E26911]          
01  100.0 [617CDA7F] [5EA0A1F0]          
02  100.0 [EA14B6A1] [9671F6FD]          
03  100.0 [9663ACE1] [D481CF8D]          
04  100.0 [16939E77] [46897AC9]          
05  100.0 [7D6384A5] [968D241D]          
06  100.0 [1DFA3E02] [202A1D6A]          
07  100.0 [FBDB8CDB] [997114D6]          
08  100.0 [5985FAC9] [3283B7DB]          
09  100.0 [59421096] [477547CE]          
10  100.0 [99E1FE74] [8FEB880D]          
11  100.0 [ABF90345] [539B6177]          
12  100.0 [08FF968A] [BF12DEDD]