MOC preloads VBR files?

Submitted by mjoedulv on Thu, 2006-02-09 22:35

Forums:

I have a network directory on a Windows box mounted via samba. When I select a VBR-encoded mp3 on this directory, there is a long delay (up to a minute) before playback starts - the longer the mp3, the longer the wait. If I have deduced correctly, this is because MOC is preloading the whole VBR file to determine its length before starting playback. Normally, this wouldn't be a problem, but because out network is wireless and old, this preloading happens at a crawling 350KB/s.

Is there any way to prevent this preloading? MOC claims to support Xing headers. That would solve the problem as the track length is saved in the Xing header. However, this problem still happens with Xing-header equipped mp3s - I think. Maybe my experiment with mpgedit didn't work after all...

Thanks,
Andi

daper

Fri, 2006-02-10 07:41

Yes, this is because of the lack of the time information in the Xing data. There are such bad files. Are you sure that this mp3 has Xing header with time? Does mpg321 -v file also work this way? Time information is needed for seeking and there is no way to turn it off.

One solution would be to have OutputBuffer set to few megabytes, MOC would then start precaching the next file to play earlier, so only the first file you select from the playlist/directory will be loaded slowly.

I know there are programs that can fix such files, after a quick googling I found this: http://www.willwap.co.uk/Programs/vbrfix.php. Works also on linux.

--
Damian Pietras - MOC developer

etatoby

Sat, 2006-03-18 19:56

I'm suffering from the same problem.

I play my music over NFS. My wireless connection is fast enough to stream even the biggest flac or wav files, but not enough to read the whole file in a blink as if it were on a local disk. Sometimes I have to wait for several minutes before MOC starts playing the file, especially if it's a continuous 'tape mix' or concert mp3.

Would it be possible to either:

1. have a config option to disable seeking into problematic files;
and/or
2. have MOC start playing the file, using leftover bandwidth to eventually compute its size and allow seeking—you could just have the playing buffer code interrupt the size-computing code every time the buffer goes under a certain size... no need to know the connection bandwidth to calculate the leftover one!
and/or
3. keep a cache in .moc so that the preloading is only needed the very first time you play a file—maybe indexing on the file size and on the first few audio frames, so that moving/renaming the file wouldn't invalidate the cached data.

A possibly related problem, although not as annoying, happens when I shut MOC down (either q or Q.) The status line goes into "Reading tags..." mode and stays there for a bunch of minutes before MOC actually quits.

daper

Sat, 2006-03-18 21:28

Why can't you just fix those files?
--
Damian Pietras - MOC developer

etatoby

Wed, 2006-03-22 11:32

Because:
- They are the great majority of mp3 files, since LAME apparently doesn't put that time information. Or maybe it does and MOC can't read it? Fact is, MOC transfers my LAME 3.9x files whole before starting to play them.
- I don't trust a random obscure utility not to ruin my files, at least not until I've tested and reviewed it myself, which will take time.
- I'm not too keen on changing all the files I download, for example if they come from BitTorrent I cannot seed them anymore.
- Sometimes I want to play files from read-only media or from friends' collections that I cannot touch.