You are here: Home » Topic » Song length detection in vbr mp3s

Song length detection in vbr mp3s

This topic contains 13 replies, has 3 voices, and was last updated by  rpedde 10 years, 6 months ago.

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #1173

    grebo
    Participant

    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?

    #9519

    CCRDude
    Participant

    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.

    #9520

    rpedde
    Participant

    @grebo wrote:

    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?

    Can’t rightly remember when I stared reading xing tags. Might have been after 0.2.4. If iTunes corrects it immediately upon starting, then that’s probably what it is.

    You can either change to 2, and delete the songs.gdb and restart, or switch to nightlies. I think either of those will take care of it.

    — Ron

    #9521

    grebo
    Participant

    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”?

    #9522

    rpedde
    Participant

    @grebo wrote:

    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.

    — Ron

    #9523

    grebo
    Participant

    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.

    Thanks again.

    #9524

    CCRDude
    Participant

    Well, it’s not really metadata, it’s more the data itself ๐Ÿ˜‰
    Bitrate, sample rate, stereo mode, copyright, original & private flags etc. are all part of the data itself.

    I’ll probably try to see if I can find any Xing-encoded file here; I remember I ripped a few albums using Xing software, many years ago ๐Ÿ˜‰

    #9525

    grebo
    Participant

    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.

    #9526

    CCRDude
    Participant

    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).

    #9527

    grebo
    Participant

    Do you just want me to send you a track from my library as a reference? (I just confirmed I used LAME 3.96 for encoding.)

    The shortest track is 4 seconds. It’s 90KB and most of that is probably the album cover.

    #9528

    CCRDude
    Participant

    Lame 3.96 does this as well? In this case I can probably find it myself, let me take a look… yes, I found it!

    Btw, here is a description of the Xing header I just found and used for implementing:
    http://www.codeproject.com/audio/MPEGAudioInfo.asp

    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.

    #9529

    rpedde
    Participant

    @ccrdude wrote:

    Lame 3.96 does this as well? In this case I can probably find it myself, let me take a look… yes, I found it!

    Btw, here is a description of the Xing header I just found and used for implementing:
    http://www.codeproject.com/audio/MPEGAudioInfo.asp

    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.

    #9530

    CCRDude
    Participant

    Click for trMP3Length.zip (Windows only currently, didn’t find the time to port to FreePascal/Linux yet)

    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 /debug

    Would 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.

    #9531

    rpedde
    Participant

    @ccrdude wrote:

    Click for trMP3Length.zip (Windows only currently, didn’t find the time to port to FreePascal/Linux yet)

    Beauty. Nicely done, sir.

    — Ron

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.