Clip+ FF/REW issues in long VBR MP3s

When I seek in long VBR MP3s, my Clip+ ends up in a different location each time. Also, when I come closer to the end of the file, the position in the progress bar exceeds it’s maximum, so obviously it doesn’t calculate the length of the file properly. I read somewhere that this was fixed in a previous firmware release but I’m experiencing it on 01.02.13.

If it helps troubleshooting, the files I’m having troubles with are available here: http://mises.org/media.aspx?action=category&ID=66 

can you try updating to the latest firmware and let us know if you still have the same issue. there is a post at the top of this board with the update and instructions. 

I tested on .13 and .15 and i am not seeing the same issue. note that the longer you hold the fast forward or rewind button the faster it will get. this was what was changed in a previous firmware to make scanning through long files faster. 

The same issue happens with me. I rewind 2 seconds and I get back 3 minutes, same when I fast forward. Actually, this happens with me with audiobooks, and I’m not sure, but I think that not only with VBR files. With the latest firmware. Please fix this, it would be really important for me!

@nero1996 wrote:
The same issue happens with me. I rewind 2 seconds and I get back 3 minutes, same when I fast forward. Actually, this happens with me with audiobooks, and I’m not sure, but I think that not only with VBR files. With the latest firmware. Please fix this, it would be really important for me!

If your file is really long (several hours or more) thats probably normal.  MP3 has no official way to handle seeking, and the informal way of doing it involves the encoder writing a seek table with just 1 hundred entries.  So if your file is 3 hours long, you will be off by several minutes per seek.  

Well, my files are 30-40 minutes. Do you think that this can happen at this length?

Oh, and of course I mean that I rewind 2 seconds so: 20:34 -> 20:32, but I can hear that the audio I hear is earlier with about 3-4 minutes. And at the end - as cpx said - it exceeds its borders.

@nero1996 wrote:
Well, my files are 30-40 minutes. Do you think that this can happen at this length?

40 minutes * 60 seconds/minute / 100 points =  24 seconds between seek points.  

Please look at my last post.

Ooo I think I know the reason. It’s because the extremely low bitrate! 32 kB/s (it was recorded 30 years ago from a radio to a tape, then digitalized). I had another file with the same length but 192 kB/s, and everything was perfect.