Hi, I just installed mt-daapd 0.2.4 on Ubuntu edgy. (Great work, very easy to install, don’t know why it’s not in the repository…)

I considered the scan_type setting but left it at 0 so I could get up and running asap.

So the song lengths are all wrong. Yes, I read the comments and expected this (most of my collection is lame-encoded VBR mp3s), but when I play a song in iTunes, it corrects the length instantly. It certainly feels like iTunes is reading some metadata that mt-daapd doesn’t look for, but could.

Anyway I thought this would be a FAQ but I can’t seem to find any discussion on it in the forums here. Can anyone comment on this? Should I be looking at the nightly builds?

Could you confirm whether there are length tags inside the files? I guess many ID3 taggers do display the length fields somewhere (TagsRevisited does it in the main view, ID3-TagIt in the tag window, Details tab, for example).

With scan_type set to 2, the scanning doesn’t take much longer though; a few minutes (less than 5 for 20k+ songs on a slow NAS) the first time, that’s all… so maybe you should switch to 2 and tell it through the admin interface to do a full rescan.

Okay I had a look at the id3 tags and can’t find anything that looks like the length. I used id3info (part of id3lib) and then tried TagsRevisited on my Windows box. Neither shows any tags the other misses out and neither shows any length tag. I suppose that confirms there is no such tag!

Then I decided to have a look at the tags in iTunes and found it shows the song’s length down to the number of milliseconds. It then dawned on me that it must have the exact length in there somewhere for the gapless playback. I did a search for ‘gapless’ on the hydrogenaudio forums and found this comment:

enc_delay and enc_padding are two fields from the “LAME header” enabling gapless playback. The LAME header usually follows directly a Xing/Info tag which both are located in the first MP3 frame

Now it all makes sense. Is this what you mean when you say “xing tags”?

Okay I had a look at the id3 tags and can’t find anything that looks like the length. I used id3info (part of id3lib) and then tried TagsRevisited on my Windows box. Neither shows any tags the other misses out and neither shows any length tag. I suppose that confirms there is no such tag!

That tag is TLEN. It should be filled (at least!) for vbr mp3 files, where the content length can’t be determined based on bitrate and data length. Not all tagger/encoders do that though.

The Xing encoder, which was the first encoder to support VBR, added a “fake” mp3 frame at the start of the data that held information about the total number of frames in the song, which helps programs like firefly figure out what the song duration is.

The problem you are seeing is that I’ve always read TLEN as a valid tag, but your song doesn’t have a TLEN tag. iTunes reads the Xing data at the start of the data and can therefore calculate the right duration of the song.

Only nightlies currently reads the xing tag. So you can either use brute force to find the number of frames in the song (option 2), or you can upgrade to nightlies (which will read the xing tag, and won’t have to brute force the frame count).

enc_delay and enc_padding are two fields from the “LAME header” enabling gapless playback. The LAME header usually follows directly a Xing/Info tag which both are located in the first MP3 frame

Now it all makes sense. Is this what you mean when you say “xing tags”?

Right (ish). About the xing tag, anyway. The gapless tag is another story.

That tag is TLEN. It should be filled (at least!) for vbr mp3 files…. Not all tagger/encoders do that though.

Right, now I see. I found this was added to lame only recently (v3.98a11) fwiw.

I went ahead and downloaded the latest nightly and it does indeed produce correct times. (Thanks!) It looks like things have come quite a way since the stable release (the .deb pkg is more than four times the size and now requires libsqlite0).

Right (ish). About the xing tag, anyway. The gapless tag is another story.

I shall go and read up on this some more. I didn’t know there was metadata outside the id3 tags. Maybe I can find a tool that will read the xing tag and write a TLEN tag to my collection.

I’ve found some info about the Xing and LAME info in the first frame and can see it in my mp3 files. But I can’t find any command line utilities that will decode and present it! Any ideas? If there’s nothing around, I might have to write one or find an existing one to extend.

If you could give me some more information I could look for (I’ve got the code to identify mpeg frames, so I would basically need information that would help me find a file I could use for testing in my collection), I could make integrate it into TagsRevisited or come up with a small stand-alone one (maybe for Linux as well, would have to check if my Unicode handling is compatible).

Something interesting: the files I ripped using CDex show a different default TLEN than this field! (only a few milliseconds, but still)…

Well, code has already been implemented roughly, just need to give it a short test with a few more files.

That’s the page I used as a reference too. Currently to determine song duration I use TLEN first, then Xing (if present), then frame counts (if mode 1 or 2), and if all else fails, data length and bitrate.

A quick command line solution for now (I’m out of the house for most of the week, so I don’t have time for more right now), which parses all specified mp3 files in a folder, and adds or updates TLEN fields in existing ID3v2 tags.

Usage:trMP3Length *.mp3 /recursive /debugWould show actions that would be done on all mp3 files in the current folder and subfolders. Add /udpate to not only add TLEN where its missing, but also correct TLEN where it’s different from the Xing field. And if everything looks ok, use /write as well to actually have it write the changes, so once you’ve verified everything is correct, use:trMP3Length *.mp3 /recursive /debug /update /write

Disclaimer: Trying this on a copy of a single folder first is recommended, just to make sure it doesn’t conflict with your style of tags. It won’t do anything if it doesn’t recognize the tag (e.g. it won’t deal with ID3v2.2, only with ID3v2.3 and ID3v2.4) and understands even unsynchronizing and unknown fields, but who knows, the ID3v2 standard has been interpreted in a lot of different ways by some.

Oh, and since Ron mentioned the nightlies already know even more methods to determine it, just regard this as “tag beautification”, not as something important, if you’re using a nightly 😉

If I find the time, I’ll probably see if I could implement the other ways as well if Xing tags are not present (like I just saw with iTunes-generated MP3 files), as well as VBRI frames.