After installing fb2k v0.8.3 I noticed very slow seeking in .mpc files. After some research I found out that the .mpc fastsearch hack has been removed in this version because some people have had problems with it.

I never had a "problem" or an "issue" with this hack, so I'd like to use it in the current version and in versions to come. Is this possible? How?

you could replace foo_input_std with an older version.

I recently had a problem playing a large mpc with a cue file on a P4. The output wasn't gapless anymore, but had something like 1 sec gaps when I was halfway the album!

This would explain the probable cause.

Off-topic, MPC is gapless, why did you need to rip the whole album to a single file, anyway?

Thx for the advice, ilikedirtthe2nd

@ GeSomeone
This has nothing to do with gaps. When the audio player advances to the next track, the whole .mpc file has to be decoded from the start to the position of that track.

The "gap" you experienced was due to this decoding procedure.

This is why it does not make sense to create one .mpc image + cue.

Yet I'm wondering: Why is even foobar that stupid? Why does it again decode the image from the beginning, when just advancing to the next track? It could just keep playing the image ;-)

Inputs are handled by independent service classes which are instantiated by the core or other services when they are needed, then deleted when they are no longer needed.

Originally, a seektable hack would have worked for this, as the next instance of the CUE input would create an input helper for the same referenced file, which would probably still have a cached seektable entry in the MPC decoder.

The problem is, the seeking hack has some "minor" problems due to how backwards data dependency works in Musepack stream version 7. Most people do not notice the problem, while a few others have reported it as missing bass for 1-2 seconds after a large seek/skip into the file.

I'll see if it's possible to implement a more foolproof and accurate way to cache information for seeking. It would certainly require more memory than the existing hack, though. At least, I think.

Thanks Leviathan and kode54,
I did understand what was going on, drawing obvious conclusions from the first article of this thread. I also know about Musepack being gapless. But I didn't know how cue files are played track by track.
I just wanted to illustrate a side effect of the slow seeking.

Just a thought, how about using something like the old seek table hack, but start decoding roughly 2 or 3 seconds before where you should start playing, instead of from the beginning. This might solve the occasional "minor" problem.

I personally prefer the old behaviour because, when I don't seek it's not an issue and when I do I'd rather choose 1 second lack of bass over 1 second waiting for sound. (1 sec. is just an example here )

On sample I had it was a very loud hi-freq artifact rather than "no bass".