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: 1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files? (Read 8517 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Unfortunately my English is bad, but...

I use foobar2000 a very long time (0.8.x or even 0.7.x, I don't remember exactly) and I have never had any problems with mp3, until not updated to v1.3.x. Not all of the files, but not less than 2/3 of the total.
Why? I read FAQ and I don't understand: why in version 1.2.9 everything is fine, but in v1.3.0b1 or higher - suddenly no? I thought that the problem in FFmpeg (after update 1.1.1 -> 2.x), but MPC-BE also use FFmpeg and has no problems (MPC-BE v1.3.1.0 -dev build 4146 with FFmpeg 2.1 git-c09bb235).

I used full portable installation and tested v1.3.0b1/v1.3.0b2/v1.3.0b4/v1.3.0b5/v1.3.0b6/v1.3.0b7/v1.3.0 final/v1.3.1b1 with
Win7x64 (Asus M5A99X Evo, AMD Phenom II X4 965, 2x4 Gb RAM, Sapphire Radeon HD 6850) and Win7x86 (HP Pavilion dm1-4000er).

My "short" experiment:
1. Install clean OS, install drivers: SATA, USB3.0 (Asmedia), JMicron, reboot.
2. Install network (Realtek) and sound (Realtek) drivers, after reboot:
v1.2.9 - works fine, v1.3.0b7/v1.3.0 final/v1.3.1b1 - works fine.
3. Install .NET Framework 4.5.1 (for AMD Catalyst Control Center), after reboot:
v1.2.9 - works fine, v1.3.0b7/v1.3.0 final/v1.3.1b1 - not.
4. Launched in console:
"C:\WIN~\Framework\v4.0.30319\ngen.exe executequeueditems"
"C:\WIN~\Framework64\v4.0.30319\ngen.exe executequeueditems"
, after reboot:
v1.2.9 - works fine, v1.3.0b7/v1.3.0 final/v1.3.1b1 - not.
5. I uninstalled .NET Framework 4.5.1 through "Uninstall a program", reboot:
v1.2.9 - works fine, v1.3.0b7/v1.3.0 final/v1.3.1b1 - not (but is less common).
What is it? What do I do?

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #1
Everything looks fine here, what problem do you exactly have? Playback problem?

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #2
When I move the slider seekbar forward, playback does not begin immediately, but with a pause 1-2 seconds (only mp3 and only in 1.3.0 beta 1-7, 1.3.0 final and 1.3.1 beta 1).

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #3
I've tried everything, sorry, all good here.

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #4
I saw only one message with this problem (on Russian forum) and I hoped  I will try to gather more information in the near future, please don't remove or close the topic.

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #5
Pause there for a clean system too, but much less. After installing .NET Framework 4.5.1 pauses appear more and more pronounced (longer).
Additional checked
experiment 1 - install .NET Framework 4.5.1;
experiment 2 - install over a previous 4.0 -> 4.5 -> 4.5.1:
in the second case, the problem is more noticeable. I don't understand what is the relations between them

Unfortunately I can not get to create conditions without pauses and with pauses, and to find the difference. I don't know what to do and I guess I skip versions 1.3.0 and 1.3.1.

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #6
Because mp3 does not support seektables for sample-accurate seeking, foobar2000 decodes the file up to the point that you seek unlike with all other formats that do support sample-accurate seeking.

It's possible that ffmpeg is slower at decoding mp3. No idea.

MPC-HC does not do sample-accurate seeking.

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #7
I have exactly the same problem, and while i've been a happy foobar user for decades, i'm sorry to say that this problem is ruining my experience.
It's exactly the same as Skif_off described, but to show you the whole seriousness of this situation i've shot this video for you:

youtube.com/watch?v=SN3Z-tCOEzg

Also, today i tried my latest downloads and added about 10 new albums - i've noticed that none of them had the delays
maybe it has something to do with the playlist changes

Anyway, Please fix this problem asap!

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #8
What is the audio device set to under Preferences > Playback > Output?
Windows 10 Pro x64 // foobar2000 1.3.10

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #9
What is the audio device set to under Preferences > Playback > Output?

thanks for your reply,
good question. it's the default windows audio output, here's the screenshot:
http://someimage.com/OUiDhn2
however i already tried all of the in regards to this problem - it has no impact on these delays.

and don't forget that before 1.3 update i never had similar problems.

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #10
Strange, everything works fine here.
Hopefully Peter may know some more.
Windows 10 Pro x64 // foobar2000 1.3.10

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #11
Because mp3 does not support seektables for sample-accurate seeking, foobar2000 decodes the file up to the point that you seek unlike with all other formats that do support sample-accurate seeking.

I know, but v1.2.9 works fine, without pauses.

What is the audio device set to under Preferences > Playback > Output?

The same + I tried WASAPI too.




1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #15
had to manually save all my playlists, because 1.2 doesn't read 1.3's playlists...

That's why 1.3 keeps the 1.2 playlists in a different folder.

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #16
Maximus Saint
Have you tried version 1.3.1 final? I have no changes

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #17
Skif_off, that's for letting us know, will save myself time and stay with 1.2.9 for now...

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #18
Version 1.3.2 without changing

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #19
Could you try other apps as well? XMPlay, 1by1, AIMP3, VLC, MPC-HC? Just to test the problem, didn't mean instead foobar2000.

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #20
eahm, VLC 2.1.3 x86, MPC-BE 1.4.3.4793 x86, Daum PotPlayer 1.6.46599 x86, all decoders with default settings - without problems.
Windows Media Player without problems too.
However:
1by1, audio decoder mpglib.dll or ACM - much less than in foobar2000;
1by1, audio decoder BASS audio library - less than with mpglib.dll or ACM.

P.S. I thought that the problem can be determined by comparing the versions 1.2.9 and 1.3.2, but FFmpeg also been updated and seems to be not so simple

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #21
If you didn't try AIMP3 and XMPlay because of their setup/installation:

AIMP3 can be installed as portable just like foobar2000, XMPlay can be extracted with 7-Zip or similar (Bandizip etc.) so, portable as well.

Don't know if it changes much but I just want to make sure it's the PC and not foobar2000.

Thanks.

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #22
I just don't like AIMP3  Checked for more information: AIMP3 3.5.5.1345 & XMPlay 3.8.0.5 - no problems.

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #23
There can not be any debugging happening unless someone provides a sample file that displays the problem.

1.3.01-1.3.0-1.3.1b1: Why is seeking so slow while playing MP3 files?

Reply #24
I take back the need for a sample. I set up a Windows 7 test environment with slow external media with MP3 files and managed to replicate the problem. I'm confident we'll get a fix in a future version.