On 8/30/05, Linus Nielsen Feltzing <firstname.lastname@example.org> wrote:
> Martin Borus wrote:
> >> Is it possible that the calculation of these values fails in Rockbox
> >> for extremely large files?
> >Yes it does. The MAS chip has a limited frame counter, and once it
> >overflows, Rockbox can't determine the number of frames in the
> >recording. Rockbox then generates a VBR header where the frame count is
> >absent (which is perfectly allright, according to the Xing
Hmm, the two windows applications I use most (Winamp and mp3directcut) both
do not know this. The result that fast rewinding is blocked on both and fast
forwarding only works in very small unusual steps.
This also happens if you have enabled the prerecording feature.
> Unfortunately, the manual fails to mention this...
> > If this can't be fixed, it might be useful to make the VBR header
> > optional in 2.5
> We could always leave out the VBR header for long recordings, but then
> many players (including Rockbox) will not detect that it's a VBR file,
> and will have problems playing the file.
For the Archos recorder I've never had serious problems with navigation in
long recordings without the header. Even if the specification allows the
absent frame count: it doesn't help if the software used to play the files
doesn't know this. So I'd prefer no VBR header to one that causes problems.
(Or an option to turn the VBR header off)
The solution is to run the vbrfix plugin on the file. Hold Play on the
> file in the browser, then select "Open with" and then "vbrfix".
Have you tried this on a 1.5 GB file? I assume this will not really work. It
"forever". (I tried this once a year ago and the unit was blocked for a long
time. I don't remember, if it finished before the batteries went dead...)
Normally, to fix the problem I load the entire file into mp3directcut and
save it again.
Which I'd like to avoid.
Just for fun I will try VBFfix on the file tonite and post if it worked and
how long it takes.
Received on Tue Aug 30 09:20:35 2005