Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: "On-the-spot" VBR Indexing (Read 8883 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

"On-the-spot" VBR Indexing

I have to confess I didn't know VBR-encoding existed until the other day, when I was given a bunch of mp3's that included various examples - some with Xing header, some with VBRI,  and some without any form of seek-position mapping information at all (still can't find a "live" MLLT example).

I write my own player software (Win32 platform),  so after reading all about the various tag or header systems for VBR seek-tables, I decided to respectfully ignore them all and simply determine track length and seek positions on the fly.

The idea of storing helper tables of some form inside the mp3 file itself, rather than  scanning the file on demand, probably made very good sense back when it was introduced.  What constitutes a "performance hit", however,  is very different now compared to then.

I wrote a routine that gets called whenever I insert a track into the current playlist - the file is loaded into RAM, completely frame-scanned, and if it's VBR the exact time is calculated and a position lookup table (to a nominated number of msecs accuracy) is built.

On my 2GHz cpu (1Gb RAM) system, the cost-per-file (3mb - 5mb) is about .025s, or about 40 tracks/second.  In terms of how fast I can click on tracks to select, it is next to no cost at all.

I am left wondering why none of the more (in)famous off-the-shelf players seem to have realised this. The only one I've seen attempt to handle a headerless-VBR is WinAmp, which keeps adjusting the track-length estimate as it reads more and more frames.

How quickly that converges to the right value depends of course on how small the early frames are relative to the true average, but it's certainly better than Win Media Player, which without a VBRI or Xing header,  is lost as far as track length and cue-to-position accuracy is concerned (unless by some happy coincidence the first frame is of very close-to-average length).

WinAmp is still easy to confuse, of course, in these situations - all you have to do is start dragging the cue slider back and forth as soon as it starts playing, before it's read enough frames, and it all goes pear-shaped.

Anyway, no big deal, I just thought I'd offer this up for comment (or flaming, whatever!)


Jim White
ANU
Canberra

"On-the-spot" VBR Indexing

Reply #1 –
That sounds great. this would allow for accurate editing if incorporated into an editor.

Maybe you could forward your code to the Foobar 2000 maker to see if he wants to include it.

"On-the-spot" VBR Indexing

Reply #2 –
Quote from: Mathimagics on
I wrote a routine that gets called whenever I insert a track into the current playlist - the file is loaded into RAM, completely frame-scanned, and if it's VBR the exact time is calculated and a position lookup table (to a nominated number of msecs accuracy) is built.

On my 2GHz cpu (1Gb RAM) system, the cost-per-file (3mb - 5mb) is about .025s, or about 40 tracks/second.  In terms of how fast I can click on tracks to select, it is next to no cost at all.

All players do this with AAC streams, unfortunately. I believe you're gonna feel a performance hit when loading many files in the playlist! Or long files, such as theatrical performances.

"On-the-spot" VBR Indexing

Reply #3 –
Jim, you might want to contact Ian Luck at http://www.un4seen.com

I think his player app, XMPlay 3.4, does something along these lines if you enable "Verify File Content" in the settings.

"On-the-spot" VBR Indexing

Reply #4 –
There is a thing called cue sheet and image file (Yes, this does exist for MP3 too, with some of the reasons being accurate length for continuous albums)

And foobar2000 already has sample accurate seeking.

"On-the-spot" VBR Indexing

Reply #5 –
Quote from: Mathimagics on
but it's certainly better than Win Media Player, which without a VBRI or Xing header,  is lost as far as track length and cue-to-position accuracy is concerned (unless by some happy coincidence the first frame is of very close-to-average length).
Huh? I use WMP11 with loads of VBR files, and I've been using WMP since v8. WMP's handled VBR seeking and track length very well since v10. Where it fails sometimes is misreporting the bitrate of a track in the library until it's played all the way through. But even then, a mouseover on the lower left of the window coughs up the correct VBR in v11, and v10 displays the same in a rotating marquee at the bottom of the player window.

As for track length itself, I have yet to see more than 1s length difference between fb2k and WMP10+ for the same VBR track, and for what it's worth, even foobar and dbPoweramp sometimes disagree, but again I've never seen a difference of more than 1s.
EAC>1)fb2k>LAME3.99 -V 0 --vbr-new>WMP12 2)MAC-Extra High

"On-the-spot" VBR Indexing

Reply #6 –
Thanks for all the feedback.  I'll respond to one point at a time.


Quote from: LANjackal on
WMP's handled VBR seeking and track length very well since v10.


Perhaps all the VBR mp3's in your library have Xing headers?

In the screenshot below,  the playlist has 4 different verions of the same track, in CBR, VBR with Xing header (encoded by LAME), VBR with VBRI header (Fraunhofer), and VBR with neither.  As you can see, WMP (v11) only has one of the 3 VBR times correct, the one with the Xing header. 

When the time is significantly wrong in the playlist, then you also get very noticable seek-to-position errors.

Screenshot 
Gnuts! This forum doesn't seem to allow file attachments,  and I don't have a website (they're against my religion) so I can't put in an image URL.

You'll just have to trust me here!


Code: [Select]
WMP Version 11.0.5721.5145

  Format    Reported length
    CBR         3:43
    VBR+Xing    3:43
    VBR+VBRI    5:00
    VBR no tags 4:42



I haven't used foobar, so can't comment on that.

Most encoders with a VBR option would probably make a header, so if you've never spotted WMP making obvious mistakes it might be because all your VBR files have Xing headers.  Lame 3.97 certainly does this by default (unless you use the -t option to suppress it).

You can use LAME to convert existing mp3's to VBR, with or without a Xing header, so anybody who has not seen this problem can easily reproduce it.

"On-the-spot" VBR Indexing

Reply #7 –
I guess not many people here use Nero products for playback or editing audio, but just to note that Nero products support Xing and VBRI headers and scan a complete stream in case that those headers are missing. So correct duration will be reported for all types of VBR files with or without headers.

"On-the-spot" VBR Indexing

Reply #8 –
Quote from: WonderSlug on
Jim, you might want to contact Ian Luck at http://www.un4seen.com

I think his player app, XMPlay 3.4, does something along these lines if you enable "Verify File Content" in the settings.


Ah, I've come across him, or at least some of his work (BASS) before. 

Now that I've looked at XMplay I would say yes, he has implemented dynamic VBR handling much as I described. 

For tagged VBR, I see that he supports both the Xing and VBRI tag formats, so times for these are displayed correctly from the time of insertion into the playlist.

The real test of interest here is the raw VBR format (ie. no timing info).  From what I can see, he always scans these files before they are first (wrt current playlist) played.

The "Verify File Content" option only affects when this occurs. If the option is ON, he scans all files at the time of playlist insertion.  Since all the timing info is available when verifying the frames, the correct track time is then shown in the playlist.

If the option is OFF, the scan is deferred until the track is first activated.

Either way, cue-to-position always works from the very start of playback, so he definitely passes my VBR-handling tests ...  and is the first player (apart from my domestic mongrel software) to do so

"On-the-spot" VBR Indexing

Reply #9 –
Thanks for that Nero info - I'm not surprised it works with tagless VBR,  it seems to me any decent contemporary player software should. 

Equally, I'm not at all surprised that WMP doesn't handle it, or even VBRI, if you know what I mean   


PS:  Does muaddib know of any encoders/decoders that use the ID3v2.3 "MLLT" tag?

PPS: I'll add Nero to my list of "good guys"!  (I do use Nero for CD burning, by the way!)

"On-the-spot" VBR Indexing

Reply #10 –
Quote from: j7n on
All players do this with AAC streams, unfortunately. I believe you're gonna feel a performance hit when loading many files in the playlist! Or long files, such as theatrical performances.


Let's say I select 100, or even 1000, tracks from my local file system, and drop them into the playlist in one operation - an intelligent player will immediately add the track titles to the display, leaving the times blank, or setting them to "??", or the estimated time.

A background thread (or just a timer-activated routine in a single-thread model) will start scanning them, filling in exact times, and creating lookup tables where applicable, as it goes.

The update routine knows which section of the tracklist is currently visible at any time, so can give priority to those, so it can react to the user scrolling the tracklist.  At the track-scan rates I'm seeing, I'd expect the visible tracks to have their track times correctly displayed in the time it takes me to realease the scrollbar!

"On-the-spot" VBR Indexing

Reply #11 –
The original MAD plugin for Winamp v0.14.2b is one of those who don't believe in the Xing frame. It always walks the whole stream during playback and would do that also before adding files to playlist, if fast playing time calculation is off.

"On-the-spot" VBR Indexing

Reply #12 –
WinAMP and XMPlay both had smart VBR handlers (XMPlay the better one), but I'd never use either player on a regular basis,not when they use the horrid Windows Common Dialog window as the browse(add tracks) tool - that canned dialog  window should have been taken out and shot years ago!

Try picking multiple tracks from any one folder and get them into the playlist in the order you selected them ....  yecch! 

"On-the-spot" VBR Indexing

Reply #13 –
j7n queried performance of full file-scans, and I quoted a time of 0.025s, but now have to 'fess up that today the results were more like 0.25s ...  a sub-editor's error!

Very large files will take a few seconds - so the list display mechanism will certainly have to be smart - I've got 2Gb of tagless VBR's (387 tracks from 3mb to 26mb) assembled in one folder, that will make a pretty good test case. I'll see how I go ....

"On-the-spot" VBR Indexing

Reply #14 –
Quote from: Mathimagics on
PS:  Does muaddib know of any encoders/decoders that use the ID3v2.3 "MLLT" tag?

No. But if anybody does, please report so that Nero decides whether we need to add the support for it.

"On-the-spot" VBR Indexing

Reply #15 –
I searched Google long and hard but could find not even a hint that anybody has actually used it.

Am I right in thinking that ID3 isn't particularly popular (v2.2 and up, at least)??

"On-the-spot" VBR Indexing

Reply #16 –
ID3v2.3 is extraordinarily popular.  Probably most MP3's encoded in the last 5 years have this tagging format.  ID3v1 tags are included as the two formats can be used together.

Some people on hydrogenaudio espouse APEv2, but this format is only easier to implement for developers, not better for the user.

"On-the-spot" VBR Indexing

Reply #17 –
Ok, it's a semantic problem - "supporting ID3v2" does not necessarily imply the use of the MLLT for VBR lookup tables.

LAME, for example, will write ID3v2 tag data, but if it writes a VBR lookup table,  it always does it in a Xing header, irrespective of other options.

I've yet to find any decoder claiming to support MLLT (they may still exist, of course), but then again I can't yet find an encoder that will create it.

Google searches I've made have turned up only references to code which is intended to recognise the existence of MLLT as a valid ID3v2 frame type, but nothing about anybody using it, encoders or decoders!

It's all a bit of a mystery!

"On-the-spot" VBR Indexing

Reply #18 –
MLLT came onto the scene too late for anyone to have implemented.  The Xing and VBRI headers predate it by a bit.

Also, there's something a bit strange about putting this sort of data in an ID3v2 tag.

"On-the-spot" VBR Indexing

Reply #19 –
Quote
MLLT came onto the scene too late for anyone to have implemented.  The Xing and VBRI headers predate it by a bit.

OK, that makes sense.

Quote
Also, there's something a bit strange about putting this sort of data in an ID3v2 tag.

Less sure about that one! I'm a late arrival to this game, so to me it seems more strange storing stuff in an audio frame! But what the heck ...   

"On-the-spot" VBR Indexing

Reply #20 –
Quote from: Mathimagics on
Quote

Also, there's something a bit strange about putting this sort of data in an ID3v2 tag.

Less sure about that one! I'm a late arrival to this game, so to me it seems more strange storing stuff in an audio frame! But what the heck ...   


Because the ID3v2 tag can become easily removed from the file (for example by converting tag formats in iTunes).

"On-the-spot" VBR Indexing

Reply #21 –
Quote from: WonderSlug on
Jim, you might want to contact Ian Luck at http://www.un4seen.com

I think his player app, XMPlay 3.4, does something along these lines if you enable "Verify File Content" in the settings.


Thank you indeed for pointing me in that direction!

I rediscovered the BASS library, which has come a long way since I last  looked (years ago, 2.0!).  There is a similar switch in BASS when opening an audio file ....

Even better is that it gives me independent pitch and tempo controls, which I was enquiring about in another thread. 

It's just what I was looking for, so I'm as happy as un cochon en merde!  Merci encore!