fall back backend when necessary (or something like that)

[jesus2099]

Would it be possible to fallback backend when needed.

I still need isrcsubmit.exe because of when the ISRC are in the CD-TEXT and not in the Q-Channel (it just happened again today with one of my library’s WIGCD162 ☜ linking in case you have it).

In these case, isrcsubmit.exe has correct values (I think) as it takes all the ISRC at once from some kind of TOC instead of bad reading the Q-Channels of each tracks.

[JonnyJD]

Cdrdao reads ISRCs from CD-Text (and my cdrdao backend uses them, if none are found in the channels).
There is a windows build available, see #24 (comment)

Wasn't mediatools supposed to read CD-Text ISRCs, too?

Anyways using isrcsubmit.exe as a backend to isrcsubmit.py should be possible somehow, but would be quite difficult. Isrcsubmit.exe want's to do stuff without asking. (First thing on my virtual machine it opens up a browser tab for an unknown discId)

[jesus2099]

Using CDRDAO (on E:) says :/

ERROR: cdrdao can only use the default device!

mediatools is looking in q-chan, I don’t know if it’s looking in cd-text, it doesn’t seem so as I have some discs for which I have to use isrcsubmit.exe which is hopefully correct for those (hopefully very few) CDs.

[JonnyJD]

Yes, that is the cdrdao-windows problem. After printing that error it doesn't work? I might change that ERROR to warning. If you only have on CD drive, cdrdao might still work as expected (even if the drive letter is not D).
Cdrdao expects something like 0,1,0 as device, but libdiscid expects drive letters (like E:)
I would basically need a different device option just for cdrdao (on windows).

What does

cdrdao scanbus

give you?

What does

mediatools drive e: cdtext

give you?
Can you combine that to mediatools drive e: isrc cdtext?

[jesus2099]

Sorry I was very busy lately.
I’m not sure any more that this CD has the ISRC in its CD-TEXT, eventually (because Tau Analyser scans the surface and finds them progressively).
I want to try your commands to help you.
I want a way of knowing for sure where the ISRC are stored.

mediatools drive e: cdtext
mediatools drive e: isrc cdtext

gives no CD-TEXT info for instance

CDTEXT STARTS
CDTEXT ENDS

Other infos

cdrdao scanbus

says

3,0,0 : TSSTcorp, CDRWDVD TS-L463A, D300

This is a lame slim combo ↗ that is slide down bugs ISRC like hell with isrcsubmit.exe but not this time. I don’t know why mediatools sees no ISRC and in this case (only) isrcsubmit.exe works good…

cdrdao read-toc tata.txt

Finds ISRC on each tracks. example for start of disc and track 1 console :

PQ sub-channel reading (audio track) is supported, data format is BCD.
Raw P-W sub-channel reading (audio track) is supported.
Cooked R-W sub-channel reading (audio track) is supported.
Analyzing track 01 (AUDIO): start 00:00:00, length 03:38:10...
Found 14 Q sub-channels with CRC errors.
Found ISRC code.
Control nibbles of track match CD-TOC settings.
…

Then starting of tata.txt :

CD_DA

// Track 1
TRACK AUDIO
COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC "GBCEL0501180"
FILE "data.wav" 0 03:37:42

Do you know if it would have said that it found them from CD-TEXT if they were there ?

So anyway, a cdrdao fallback seems good. Notice that I didn’t specify any drive letter nor 3,0,0 in the command…
I don’t know why mediatools.exe doesn’t work on some CDs.

[jesus2099]

What an idiot I am !
Actually, after displaying the cdrdao ERROR everything works indeed !
So actually may I re-suggest differently something like :
Being able to give -b option a list of backends instead of just one :

python isrcsubmit.py -d e: -u jesus2099 -b mediatools,cdrdao

Would first try to find ISRC with mediatools then, if none, with cdrdao.

[JonnyJD]

The TOC output of CDrdao looks like in #17 when the ISRC is in the CD-TEXT.
isrcsubmit.py doesn't show you where the ISRC is located (it doesn't even take note of it)

I added another issue to defuse that ERROR message, because it seems to be misleading to the user: #38

[JonnyJD]

As for the actual proposal in this issue, setting a list of backends on the command line:
There is already a built-in list of backends to try. The fall back case is when a backend is not found at all.
The backends give the same result on the same drive (on the same platform). This is my experience.

The exception is mediatools, which has another ISRC search algorithm which is supposed give no duplicate ISRCs.

This release seems to be an exception for unknown reasons.
When there are more releases like this, we have to move mediatools down in the preference list.

The problem with a fall back mechanism on anything other than "backend not found" is complexity and time.
There are more reasons to try another backend: Duplicate ISRCs, no ISRCs, some ISRCs missing.

And we only have one release right now, which seems to be having problems with one backend. No reason to implement a general solution to an unknown problem.

Please keep me updated if you have more releases like this. I can only test different backens on linux and like I said: I never had different results with different backends at all. (only random duplicates that even change on multiple reads with the same backend)

[jesus2099]

OK it’s pretty rare I remember only of 5 or 6.
And I can manually set the -b backend of choice so no problem actually, let me close the ticket. :)