Hi everybody,

I haven't been reading the forum for a long time now, but, due to a reinstallation, got a new copy of foobar 0.9.1 yesterday. After installing it, I experienced extraordinary long times for scrolling/searching inside .MPC-files, which generally exceed 10 s - and which becomes the longer, the bigger the filesize is.

My computer: Athlon 700 MHz, 1.5 GB RAM, standard soundcard ... does anybody have a clue or maybe experience the same problem and may offer a solution? Precaching of files and sound cache did not succeed.

The problem becomes really annoying when I'm playing some Musepack-album in conjunction with the accompanying .CUE-file - between the track borders, I now enjoy 10s-breaks instead of zero breaks. please help!


Johannes

It's not a problem inherent to fb2k v0.9.1, because Musepack is my lossy codec of choice and I have not experienced any problems.

Well, I experienced this problem right after switching to the 0.9 codebase. Having installed the old 0.8 line in another directory, the problem dissolved, but, of course, I would like to permanently switch to 0.9, and not only for non-Musepack-files ...

the hack used for fast seeking in mpc used in 0.8.x was removed in 0.9.x, this problem is inherent of the current mpc container not of foobar

So what is the solution to the problem? Hopefully, not to continue employing the old 0.8.x codebase?

I cannot imagine that I'm the only person experiencing the problem described above - how do you solve this issue?

The change log says that hack had already been removed in 0.8.3.
MPC seeking usually is quite slow, but >10 seconds is really very much. Does this happen with every MPC file you have?
I tested a 10 minute Musepack file (1.15v Standard) on an Athlon 600, 256 MBytes RAM, and seeking in it took about 1.5 seconds

I have an Athlon XP 1800+ and seeking an hour in one long MPC file (DJ set) takes about 10 seconds. Seeking in such large MPC files on a 700 mhz CPU could easily take more than 20 seconds. If you use CD Images + cue very long seeks are to be expected. The fastseek hack in 0.8 has been removed, because it can cause white noise after seeking.

Work has been done to fix MPC seeking issues - discussion can be found here:

http://www.musepack.net/forum/viewtopic.php?t=299

The problem is worse than just `noise` after seek - it could cause hearing damage if you use headphones and the file has a positive ReplayGain value.

If you use Musepack as your format of choice, sticking with the 0.8 releases seems to be a very bad idea.

I really only have annoyances when seeking a file accessed from a slow NFS or SMB share.

Thank you very much for your replies so far. Since I'm no technician, what does the given link explain to me? Is a solution for the seeking issue conceivable and "in preparation"? Or will it be deferred due to limitations of the MPC stream file format? I seem not to get a clue from this discussion ...

If I read everything correctly, a few shortcomings in the format itself are going to have to be updated to avoid "hacks", but faster seeking is being implemented in the Musepack library as well. The changes appear to be a "fast decode" when "walking" the bitstream that will allow accurate positioning without actually fully decoding all the audio data, which will speed up seeking a large amount.

To get "instant" seeks, a new version of the SV7 encoder will have to be made available that includes some changes. If I am reading this correctly, it also appears once the new encoder is released, seeking will forward by skipping to a position in the file, going back and silently decoding at least 128 frames, and then resuming playback at the required seek point. For all your files already encoded, the seeks won't be "instant" but much faster as long as the "fast decode" is CPU-bound.

Musepack already decodes pretty fast. Seeking on a slow network (such as a WLAN) will still have some delay as the contents of the file will have to be transferred. So, if I understand correctly, the most dramatic seek speed increases will likely be seen on portable devices with limited speed, such as the platforms Rockbox is targetting.

I think foobar2000 has some speed optimizations already, but the "immediate seek" hacks were removed from both the foobar2000 MPC implementation as well as the official Musepack decoding libraries due to the inaccurate decoding and the very real possibility of hearing damages. Once a new library is made public, foobar2000 changes will likely follow sometime thereafter.

I believe foobar2000 uses a rewritten C++ library for decoding Musepack that allows proper exception reporting and thread safety, and I'm very sure that Peter isn't going to implement these changes into his decoder until their implementation is known to be stable and well-tested. Either way, for decoding Musepack, you should be using the latest foobar2000 0.9 releases, or make sure that other applications are using the latest official decoder libraries - both for accurate decoding and to avoid hearing damage.

It sounds like a work around for MPC seeking has been developed. I remember seeing that Rockbox used it to enable seeking in MPC files being decoded on the Ipod.

Is it applicable to foobar?