Double Dilemma

Help
1

Hi All, brand new to Beets (first post). I recently installed it via docker, and spent a good few hours setting up the env and my config file. I started the first import yesterday afternoon, and so far it’s working wonderfully!! I’d love to buy the Dev(s) a beer, or 12… This thing is exactly what a geek like me needed to get my library in shape.

I’d like to try and explain a little problem I’ve got; with hopes that beets can help solve it…
It’s quite irritating, and a little comical really…

So my current collection is just over 100Gb; and most of those albums were ripped, by hand, in the late 90’s and early 2000’s, using tools like lame, or abcde (dating myself a bit here). Did my best to keep everything organized, and backed up over the years. At some point, the system I was using to keep everything organized was lost, which is where the problem began…

So lets say I ripped/encoded/tagged a brand new album, from CD, the day after it came out; which produced something like:
track_1.mp3 (4:25)
track_2.mp3 (6:14)
track_3.mp3 (9:21)
track_4.mp3 (12:01)

Then stored the CD, on a shelf, or milk crate for X years…
(forgetting that I already had it encoded, or loosing track via the aforementioned organization method)
Re-ripped/encoded/tagged the same album, several years later… Resulting in:
track_1.mp3 (8:51)
track_2.mp3 (12:28)
track_3.mp3 (18:42)
track_4.mp3 (24:02)

(Silly right; In the early years, programs like abcde, or others, didn’t check to see if the file already existed, it just appended to it)

So now, I’ve got a few dozen albums in my library with tracks that are exactly double the length they need to be. The tags on the files are accurate (thanks to beets), the directory structure, naming scheme, etc all look good. But when you listen to the track, it repeats, exactly twice. I hope this makes sense. If someone would like a more detailed example, I’d be happy to find one, and break it down…

Any idea how I’d rectify this?

2

Yay! Welcome to the beets community.

That’s a very interesting problem that I don’t think I’ve ever seen before. It seems like you need to do two things:

  • Find these cases, where an entire album has double-length tracks.
  • Chop off the last half of the audio.

The second step will probably involve a clever invocation of ffmpeg. The former seems like the place where beets can help most. But I think the right way to go about that would be to write a one-off, custom plugin. It could fetch the “correct” time from MusicBrainz for every track and compare it to the actual time of the audio file. This could be really simple—probably just a handful of lines of code. But I can’t, at the moment, think of a way to do it without doing a little bit of Python hacking.

1 Like
3

Thanks @adrian

Correct me if I’m wrong, but isn’t the track length stored as a tag within the mp3 file already?

If so, is there a way to analyze if the track length is longer than the length stored in the tag, then perhaps move those files to a directory to be process by hand, with ffmpeg… (processing in place would be wonderful, I’m just trying to break it down into steps).

4

The actual length of your audio file is available in the tags, but we don’t store the “ideal” length value from MB.

5

I think that makes sense; So the “Ideal” length from MB is Not stored in the tags; instead it contains the actual file length.

In this example: https://musicbrainz.org/release/2d4729f8-5b06-3303-83e7-73743c50a603
Are you calling the “ideal” length of “Strange Days”: “3:09”?

I also know about enough python to delete my entire library, by accident. I’ve been reading the docs on creating plugins, and can probably figure it out. Would you have any example plugin that performs a similar function, that I could use for reference?

6

Yep!

All the built-in plugins will be larger and more complex than you need, but you might take a look at mbsync, which also needs to fetch MB data for tracks.