Please add support for hidden track 1 audio files

[GoogleCodeExporter]

Some rippers (such as morituri) encode hidden audio before track 1 as a 
separate track (tagged as track 0) which confuses the matching that beets does. 
It would be helpful if beets were able to cope with this more gracefully.

The morituri tracks end up as "00. $ARTIST - Hidden Track One Audio" FWIW but 
I'd guess that any track explicitly numbered as zero could usefully be treated 
this way.

Original issue reported on code.google.com by broo...@gmail.com on 19 Feb 2013 at 7:41

[GoogleCodeExporter]

Thanks for reporting: this is an interesting edge case. How do you imagine this 
support working? Are these tracks typically listed in MusicBrainz, or would be 
have to import them even though they are unmatched?

If these are listed in MB, are you just suggesting that the matching heuristics 
be more tolerant of track listings that start at zero instead of one? Or is 
beets getting confused in a different way that I'm not seeing?

Original comment by adrian.sampson on 19 Feb 2013 at 10:17

[GoogleCodeExporter]

No, they're not typically listed in MusicBrainz - what ends up getting emitted 
is the MusicBrainz track listing with an extra (generally extremely short) 
track 0. I'd be perfectly happy for beets to discard them (especially if all 
the samples in the track are zero) but importing them anyway isn't the end of 
the world either.

The track numbers for the MusicBrainz listings generally start at 1 as one 
would expect, I've not noticed any starting at anything else.

At least in the case of Morituri I've actually filed a couple of bugs asking 
for this to be hidden and either added to track 1 or discarded if they're empty 
on the basis that the feature is generally useless.

Original comment by broo...@gmail.com on 19 Feb 2013 at 10:23

[GoogleCodeExporter]

Aha, thanks for clarifying. Yes, it does seem like it would be nice if morituri 
had an option to turn these extra tracks off.

Anyway, I would expect that beets would generally mark extraneous tracks like 
this as "unmatched" and continue happily along with the rest of the album. Is 
this not happening? What happens instead?

Original comment by adrian.sampson on 19 Feb 2013 at 10:34

[GoogleCodeExporter]

What's happening is that beets really struggles (mostly fails) to match the 
album with the MusicBrainz data - it looks like it's giving at least a very 
high priority to track count and trying to find a release from the artist with 
the number of tracks it physically sees and as a result coming up with terrible 
matches and offering to retag everything for some marginally related release.

This is especially ironic as Morituri refuses to rip anything that isn't in 
MusicBrainz and thus all the incoming audio should match exactly what's there.

Original comment by broo...@gmail.com on 19 Feb 2013 at 10:38

[GoogleCodeExporter]

Cool, that makes sense. Yes, beets does ask MB for matches with the "right" 
number of tracks, but it also tries to match releases with more or fewer also.

To help nail down which part of the system needs to change here, can you help 
provide a test case where things go wrong? The most helpful thing would be a 
directory of audio files that reproduces the problem, but that can be a 
headache to upload & share. Barring that, can you paste the verbose output 
(beet -v imp ...) for a session that tries and fails to match one (or more) of 
these albums?

Original comment by adrian.sampson on 19 Feb 2013 at 10:53

[GoogleCodeExporter]

Will do next time I get a CD that generates them.

Original comment by broo...@gmail.com on 20 Feb 2013 at 9:26

[GoogleCodeExporter]

Here's a log, as you can see an exact artist/title match is rejected due to the 
extra hidden track early on in the process:

$ beet -v import album/E\ -\ Broken\ Toy\ Shop/
config file: /home/broonie/.beetsconfig
library database: /home/broonie/.beetsmusic.blb
library directory: /home/broonie/Music
Sending event: import_task_start
Looking up: /home/broonie/import/album/E - Broken Toy Shop
Tagging E - Broken Toy Shop
Searching for discovered album ID: d3023564-451c-4551-a04d-4a4fa4a18a55
Candidate: E - Broken Toy Shop
Too many items to match: 15 > 14.
Album ID match recommendation is RECOMMEND_NONE
Search terms: E - Broken Toy Shop
Album might be VA: False
Evaluating 5 candidates.
Candidate: E - Broken Toy Shop
Too many items to match: 15 > 14.
Candidate: E - I adore nothing I believe It does not exist
Success. Distance: 0.691858
Candidate: E!E - E!E 0001
Success. Distance: 0.779968
Candidate: Dibia$e - Machines Hate Me
Success. Distance: 0.830182
Candidate: E-Rotic - Gimme Gimme Gimme
Success. Distance: 0.829486

/home/broonie/import/album/E - Broken Toy Shop
Finding tags for album "E - Broken Toy Shop".
Candidates:
1. E - I adore nothing I believe It does not exist [Rachot / Behémót, 1994] 
(30.8%)
2. E!E - E!E 0001 [1992] (22.0%)
3. E-Rotic - Gimme Gimme Gimme [2000] (17.1%)
4. Dibia$e - Machines Hate Me [Alpha Pup Records, 2010] (17.0%)
# selection (default 1), Skip, Use as-is, as Tracks, Enter search,

Original comment by broo...@gmail.com on 21 Feb 2013 at 10:06

[GoogleCodeExporter]

Ah, I see -- I think you have an old version of beets. Newer versions will not 
reject matches based on track count mismatches (that "Too many items to match" 
is the giveaway). Please upgrade to 1.0 or 1.1b2 and try this again.

Original comment by adrian.sampson on 21 Feb 2013 at 10:08

[GoogleCodeExporter]

Oh dear, I have 1.0b14 which is the latest version in Debian. Fortunately 
there's an updated package in experimental for 1.0 - upgrading to that does 
seem to make things a lot happier indeed, thanks.

Original comment by broo...@gmail.com on 21 Feb 2013 at 10:14

[GoogleCodeExporter]

(I would close the bug but I don't seem to have permission)

Original comment by broo...@gmail.com on 21 Feb 2013 at 10:15

[GoogleCodeExporter]

Cool. Enjoy 1.0.

Original comment by adrian.sampson on 21 Feb 2013 at 10:37

• Changed state: Invalid