Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Help with slow seeking in foobar2000 (Read 501 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Help with slow seeking in foobar2000

Hello everyone,

I've been messing around with WavPack lately and I love both the lossy hybrid and lossless formats, they both play excellently on my smart phone, when using USB Audio Player Pro (I like using this app as I'm able to utilize my DAC fully and bypass any upsampling from the Android OS). Now my problem is when I'm playing these WavPack files on foobar2000, when seeking through the tracks they have a lag before they go to the section of the song I want to hear. Now when I use ALAC and FLAC, they don't have this decoding issue in foobar2000, is there something I'm doing wrong because I've tried .wv files encoded with both the WavPack encoder and dBpoweramp,  and they both have the same seeking issue where there is a significant pause before I get to the section I want to hear.

Now just so everyone has enough information to go off by, I output the audio from foobar2000 using WASAPI because I use an optical cable to send the audio to my built-in DAC on my integrated amp, so I can have the amp process the audio and send it to my speakers, so I can bypass any upsampling from Windows. Is this the reason there is an issue with seeking, or do you guys think it might be a buffering issue or cache related? I'm relatively familiar with the lossless scene for the last 7-8 years(I actually forget when I first used FLAC :D ) but I'm no expert by any means, so if anyone can help me out I would truly appreciate it.

I'm only asking because I haven't had a seeking issue with any format I tried on foobar2000 until WavPack and I truly have a great deal of respect for the format and what it can achieve, so I'm trying to get it to work on my foobar setup.

Re: Help with slow seeking in foobar2000

Reply #1
Hello everyone,

I've been messing around with WavPack lately and I love both the lossy hybrid and lossless formats, they both play excellently on my smart phone, when using USB Audio Player Pro (I like using this app as I'm able to utilize my DAC fully and bypass any upsampling from the Android OS). Now my problem is when I'm playing these WavPack files on foobar2000, when seeking through the tracks they have a lag before they go to the section of the song I want to hear. Now when I use ALAC and FLAC, they don't have this decoding issue in foobar2000, is there something I'm doing wrong because I've tried .wv files encoded with both the WavPack encoder and dBpoweramp,  and they both have the same seeking issue where there is a significant pause before I get to the section I want to hear.

Now just so everyone has enough information to go off by, I output the audio from foobar2000 using WASAPI because I use an optical cable to send the audio to my built-in DAC on my integrated amp, so I can have the amp process the audio and send it to my speakers, so I can bypass any upsampling from Windows. Is this the reason there is an issue with seeking, or do you guys think it might be a buffering issue or cache related? I'm relatively familiar with the lossless scene for the last 7-8 years(I actually forget when I first used FLAC :D ) but I'm no expert by any means, so if anyone can help me out I would truly appreciate it.

I'm only asking because I haven't had a seeking issue with any format I tried on foobar2000 until WavPack and I truly have a great deal of respect for the format and what it can achieve, so I'm trying to get it to work on my foobar setup.

I fixed the issue, just in case anyone has the same issue as me for future reference. How I fixed it was I increased the buffer length from 200ms to 750ms. Now it works flawlessly.