Working on getting beets calibrated to my liking and ran across an issue
that happens more often then I would like.

Example output illustrating the issue:
<snip>
Tagging: Cat Stevens - The Very Best of Cat Stevens
(Similarity: 45.1%)
 * (Remember the Days of the) Old Schoolyard (17) -> Moonshadow (1)
 * Lady D'Arbanville (3:46 -> 3:43)
 * Oh Very Young (2:37 -> 2:34)
 * Matthew & Son (2:44 -> 2:41)
 * Into White (16) -> Hard Headed Woman (10)
 * Hard Headed Woman (10) -> I Love My Dog (11)
 * Another Saturday Night (20) -> Into White (16)
 * Moonshadow (1) -> (Remember the Days of the) Old Schoolyard (17)
 * Where Do the Children Play? (3:53 -> 3:49)
 * How Can I Tell You (4:29 -> 4:24)
 * I Love My Dog (11) -> Another Saturday Night (20)
 * Peace Train (4:12 -> 4:04)
[A]pply, More candidates, Skip, Use as-is, as Tracks, Enter search,
enter Id, aBort?
</snip>

As you can see there are files named closely to what they are supposed to
be (e.g. Moonshadow) yet beets thinks they should be named something else.
In a few hundred albums this has happened 6 or so times, so not happening
very often, but often enough to be something I'd rather find the cause and
address.

Also, being fairly new to beets I'm hoping to get suggestions on what to do
in these situations? For now I am Skipping them, thinking to deal with them
later, but if there is a way to get beets to deal with them I'd much rather
figure that out. So far I've tried finding the album on musicbrainz and
specifying the ID to beets.

Lastly I get quite a lot of corrections to the track length, is that
normal? Are the "corrections" to the tag info only or are they making
changes to the files themselves?

Thanks for any help.

Hey Larry,

I've run into this problem as well, and worked around it by setting the configuration file [path] section such that individual tracks are put at $artist/$album/$title, and then when I come across a stubborn album that has this behavior, I just process it as individual tracks.

The only case in which this fails is if there are guest artists on one or more of the tracks, at which point it could spread the album over two folders because $albumartist doesn't work for single tracks.

Whenever I have to do this, I just pay close attention to what the staggering does and correct it manually if necessary.

To the best of my knowledge, the track length issue stems from different versions of the same album in musicbrainz. CDs have a table of contents that specifies the length of each track and the time between each track. Most digital fingerprinting services used this as a hash to "uniquely" identify albums prior to the appearance of richer meta data. My understanding is that these values tend to vary over different manufacturing batches. As such, the length of your copy of the track probably differs from the length that was on the disc that was ripped into Musicbrainz, even though all of the other meta data matches.

Hope that helps.
--
Email: jonfr...@gmail.com
Twitter: @jonathanmfritz

Example output illustrating the issue:

<snip>

Tagging: Cat Stevens - The Very Best of Cat Stevens

(Similarity: 45.1%)

 * (Remember the Days of the) Old Schoolyard (17) -> Moonshadow (1)

 * Lady D'Arbanville (3:46 -> 3:43)

 * Oh Very Young (2:37 -> 2:34)

 * Matthew & Son (2:44 -> 2:41)

 * Into White (16) -> Hard Headed Woman (10)

 * Hard Headed Woman (10) -> I Love My Dog (11)

 * Another Saturday Night (20) -> Into White (16)

 * Moonshadow (1) -> (Remember the Days of the) Old Schoolyard (17)

 * Where Do the Children Play? (3:53 -> 3:49)

 * How Can I Tell You (4:29 -> 4:24)

 * I Love My Dog (11) -> Another Saturday Night (20)

 * Peace Train (4:12 -> 4:04)

[A]pply, More candidates, Skip, Use as-is, as Tracks, Enter search,

enter Id, aBort?

</snip>

As you can see there are files named closely to what they are supposed to be (e.g. Moonshadow) yet beets thinks they should be named something else. In a few hundred albums this has happened 6 or so times, so not happening very often, but often enough to be something I'd rather find the cause and address.

Also, being fairly new to beets I'm hoping to get suggestions on what to do in these situations? For now I am Skipping them, thinking to deal with them later, but if there is a way to get beets to deal with them I'd much rather figure that out. So far I've tried finding the album on musicbrainz and specifying the ID to beets.

Lastly I get quite a lot of corrections to the track length, is that normal? Are the "corrections" to the tag info only or are they making changes to the files themselves?

Thanks for any help.

Is there any chance that you are (a) using the "chroma" (acoustic fingerprinting) plugin and (b) using beets 1.0b14 (the most recent release)? If so, there's a bug in the chroma plugin that could cause tracks to be frivolously reordered when the Acoustid database contained ambiguous information. This bug is fixed in the latest beets source; a new version with the fix should be out Real Soon Now. The full changelog for the upcoming release is here:
http://beets.readthedocs.org/en/latest/changelog.html

If this isn't the case, the larger issue here is that beets reorders tracks because -- sometimes -- tracks really are out of order and mislabeled. It's clearly being too aggressive about that in this case, but in general it will inevitably make mistakes occasionally. That's why we're also working on an option for manually reordering tracks when beets gets it wrong:
http://code.google.com/p/beets/issues/detail?id=377

The track length "corrections" are purely informational; no change is made to any track duration.

Adrian

On Jul 20, 2012, at 11:48 AM, Larry Schwerzler <la...@schwerzler.com> wrote:

That is exactly my situation.

beets version 1.0b14
plugins: chroma, lastgenre, embedart, scrub

Great to hear that it is something that is known about and a fix is not far
off :)

Looks like great changes coming with r15 thank for all your effort :)