I was curious to know if ppl have noticed any difference in seeking performance (in FB2K) by wrapping mp3 in an mp4 container ?
By performance i an referring to seeking speed etc. and by mp3s i'm referring to mp3s that come with a CUE file. I presume the CUE would point to the wrapped mp4 file.
If i understand correctly,the reason seeking is slow for big mp3s is that they do not contain seek tables and FB2K needs to decode right up to the seek point, does a mp4 have these seek tables that speed up seeking ?
If people have noticed speed improvement, do they then prefer to wrap (all) those mp3s/CUE with mp4containers so that performance is seamless ?
Full Version: Using mp4 container for faster seeking
I posted above because i found this
and then followed the instructions mentioned in
and yet perceive no difference in seeking speed of an mp4 (mp3 wrapped in mp4) and the original mp3 file.
Am i doing something wrong ?? i have the latest FB2K (special) v0.8.3
Another question i have is i notice a little stuttering (half a second) when i click between tracks displayed by the cue file. Did not notice this using winamp2.91+cue plugin. Is there a buffer setting i need to change ?
QUOTE(zZzZzZz @ Dec 27 2003, 11:31 AM)
- MP3 inside MP4 container is a part of MPEG-4 standard, MP3 inside Ogg isn't. Hardware support for MP3-inside-MP4 is to be expected.
- MP4 allows fast sample-accurate seeking (emphasis mine) of MP3 streams, native gapless playback, use of MP4 tagging with MP3, etc.
- MP4 allows fast sample-accurate seeking (emphasis mine) of MP3 streams, native gapless playback, use of MP4 tagging with MP3, etc.
and then followed the instructions mentioned in
QUOTE(Moneo @ Mar 18 2004, 09:57 AM)
I suggest wrapping the mp3s in an mp4 container to increase seeking speed. Add the mp3 file to the playlist, right-click it, choose "mp4 utilities - convert to mp4 (same directory)". Then open the .cue file in a text editor and edit it to point at the newly created mp4.
After that you can delete the original mp3, as the whole operation is lossless and you can restore the original file by choosing "mp4 utilities - extract mp4 track(s)" from the context menu.
After that you can delete the original mp3, as the whole operation is lossless and you can restore the original file by choosing "mp4 utilities - extract mp4 track(s)" from the context menu.
and yet perceive no difference in seeking speed of an mp4 (mp3 wrapped in mp4) and the original mp3 file.
Am i doing something wrong ?? i have the latest FB2K (special) v0.8.3
Another question i have is i notice a little stuttering (half a second) when i click between tracks displayed by the cue file. Did not notice this using winamp2.91+cue plugin. Is there a buffer setting i need to change ?
If you can't notice any speedups with MPEG-4, or any slowdowns with MP3, then you don't really need MPEG-4. Not for speed, at least.
If the half-second stutter is with MP3s, then it would probably get better if you embedded the MP3 in MPEG-4.
If the half-second stutter is with MP3s, then it would probably get better if you embedded the MP3 in MPEG-4.
QUOTE(kjoonlee @ Jul 28 2004, 01:09 PM)
If you can't notice any speedups with MPEG-4, or any slowdowns with MP3, then you don't really need MPEG-4. Not for speed, at least.
If the half-second stutter is with MP3s, then it would probably get better if you embedded the MP3 in MPEG-4.
If the half-second stutter is with MP3s, then it would probably get better if you embedded the MP3 in MPEG-4.
But i notice the same stutter in mp4 as well, that is with the Cue file loaded into FB2K. I only notice the stutter when i change to different tracks in the cue file. Playing the files from the beginning is fine.
I'm not complaining about the time it takes since its preferable (to me anyway) to have sample exact seeking. I thought the seektables in mp4 would help to speed seeks. So the mp4 wrapper seemed like a promising workaround.
Could it be that FB2K does not take into account mp4s seektables during seeking ?
I don't know how exactly this works, but with some 20+minutes tracks I have I noticed a difference in seeking speed in wrapped and unwrapped mp3-s, to the favor of mp4-contained ones. Maybe this is not as perceptible with usual 3-4 minute files.
And this improvement only counts the first time seeking in a file. (Maybe foobar restarts count, at least I thnik so, I did not do much experimenting)
And this improvement only counts the first time seeking in a file. (Maybe foobar restarts count, at least I thnik so, I did not do much experimenting)
QUOTE(kalmark @ Jul 28 2004, 01:34 PM)
I don't know how exactly this works, but with some 20+minutes tracks I have I noticed a difference in seeking speed in wrapped and unwrapped mp3-s, to the favor of mp4-contained ones. Maybe this is not as perceptible with usual 3-4 minute files.
And this improvement only counts the first time seeking in a file. (Maybe foobar restarts count, at least I thnik so, I did not do much experimenting)
And this improvement only counts the first time seeking in a file. (Maybe foobar restarts count, at least I thnik so, I did not do much experimenting)
i was referring to mp3+cue, so the file length is on avg 60-75 mins. the tracks in the cue however are shorter but i think this does not matter.
i imagine the easiest test would be to pick from the last tracks in the cue. If seektables are working then FB2K would not need to walk the chain to find where that position is. Since it would query the seektable.
Another test would be to see how much memory usage had increased, again i imagine that FB2K would not need to walk the chain cos of the seektables.
I wonder why the difference is so subtle, if its *really working*. I admit, that i do have the tracks on the same computer as FB2k. The difference might be more marked if i was pulling the track of a network share.
With some extra testing i notice the following.
the mp3 does not stutter as much when jumping between tracks in the same cue(that is while another track is playing)
the mp4 stutters each time u pick a track from the cue (that is while another track is playing)
If one presses stop then selects a track its fine.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.