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.
Recent Posts
1
foobar2000 mobile / Re: Gapless broken on Android
Last post by lostgirl22 -
Quote from: MotleyG on
Quote from: Peter on
Might want to try latest preview build, I noticed that we had rather low buffer size of 1 second, with no tweak option to override. I bumped the default to 5 seconds for 1.6.2.
Sounds like what you're experiencing is a symptom of exactly this, though strangely I have never encountered the problem on my own devices, including some really low spec ones...

I'm planning to do this properly (output settings page) for 1.7.
Any idea why this needs to be such a long buffer on newer/faster devices? Seems counter to the idea of superior devices to have them need more buffer time.

I'm sure it doesn't need to be quite that long, the gap I was hearing was a fraction of a second, so I think a one-second buffer just wasn't quite long enough. But why SD card accesses apparently take longer on a new phone with a new card than they did on an old phone with an old card – pass. I'm guessing Google have "improved" Android in some way but how or why I don't know. Or maybe it's Motorola's doing: there's something called "ThinkShield" on my phone which is enabled and can't be disabled and which claims to be "enhancing protection at every level". All I can say is that reads clearly do take a fraction longer on this phone, because increasing the buffer has solved the problem.
2
foobar2000 mobile / Re: Gapless broken on Android
Last post by MotleyG -
Quote from: Peter on
Might want to try latest preview build, I noticed that we had rather low buffer size of 1 second, with no tweak option to override. I bumped the default to 5 seconds for 1.6.2.
Sounds like what you're experiencing is a symptom of exactly this, though strangely I have never encountered the problem on my own devices, including some really low spec ones...

I'm planning to do this properly (output settings page) for 1.7.
Any idea why this needs to be such a long buffer on newer/faster devices? Seems counter to the idea of superior devices to have them need more buffer time.
5
foobar2000 mobile / Re: Gapless broken on Android
Last post by lostgirl22 -
Thank you so much, Peter, and I'm very sorry for the long delay in replying: the forum didn't notify me of your post so I didn't know about it!

The change to a 5 second buffer in 1.6.2 has solved the problem for me! I'm so happy about that. Gapless is working again. If I look in the console, I can see the new track being opened well in advance of the previous one finishing, and the "Playback interrupted, source is stalling..." message is no longer shown.

An adjustable buffer in 1.7 would be great, as I think even on my problematic device 2 seconds would probably be enough.

My old phone was prehistoric compared to my new one, and it used to work just fine too – so low spec devices don't seem to be at the root of the problem. Not sure what's going on, but you've fixed it, so thank you!
6
3rd Party Plugins - (fb2k) / Re: Georgia-ReBORN - A Clean foobar2000 Theme
Last post by Jjkbuysell -
Is it of any interest to anyone to have the ability to fallback onto a web source for ArtistCountry or any other artist info really, if it is not tagged in the file?  I mean artist BIO lookups are already happening.  Could maybe cache this info somewhere in the userprofile of windows as not to do constant web lookups on each track.

Just talking out loud here, after beginning the task of adding the ArtistCountry tag to all my files.   :o
7
Support - (fb2k) / fb2k fails sampling rates below 1000 Hz
Last post by Porcus -
... as if they have much music value ...
But still: consider giving an error that fb2k doesn't support, rather than putting the blame on valid files.

Sampling rate 999 Hz:
* WavPack and WAVE files show up with question-mark length and "Unsupported format or corrupted file"
* FLAC shows up with correct length, correct MD5, but verifies to "Failed: Decoder produced invalid output".

Sampling rate 1000: OK.

Tried 1.6.14 and last week's preview-32bit fresh out of the box, portable.
8
Scientific Discussion / Re: One updated and one new audio processing DSP library
Last post by bryant -
Quote from: bennetng on
Convolution version 4 without using any double. Files within the same group are identical (also true for version 1).
Quality wise, version 4 is obviously cleaner and more consistent among different compiler settings.
Interesting that the canonical version with the "safest" compiler settings produces the worst result (If I'm reading your graphs correctly)!

I suspected that the 4th version might (jn theory) produce the best results (because it orders the adds from the smallest to the largest values), but I was never able to measure it. What's more surprising is that (again, if I'm reading correctly) the more advanced SIMD options are producing progressively better results compared to the "correct" ones. Have no guess what that would be.

It seems though that it might be reasonable to switch to version 4 as the default.
9
Scientific Discussion / Re: One updated and one new audio processing DSP library
Last post by bryant -
Quote from: bennetng on
Quote from: bryant on
BTW, is this with your "double" change for precision? And which of the provided convolutions implementations is this with?
I specifically tried mingw64 because I hate the MSVC limitations. There is no change in the original source code (i.e. 32-bit with canonical convolution). Because the comparison among different versions would be unfair for example in the 4x unroll version:
Code: [Select]
sum += (A[0] * B[0]) + (A[1] * B[1]) + (A[2] * B[2]) + (A[3] * B[3]);
Everything is still in float before adding to sum, and if I cast A and B to double within such a loop things will slow down a lot which nullify any unrolling effort.
My thinking was that the unrolled versions will let the compiler know that there are (in the case you show) always a multiple of 4 samples available, which should make the SIMD easier. But maybe it just throws in extra code to check the counts and in the case of 1024 terms it makes no difference. I'm not sure what you mean by "unfair". The fastest version would be the best unless it generated bad results (which I think in this case would just be slightly more noise).
10
Polls / Re: 2024 Lossy format poll
Last post by a.ok.in -
Quote from: Squeller on
they don't display embedded art from aac files, whereas mp3 works.
Same, I have an old TV (from 2010) with USB support; artwork from mp3 is fine, but doesn't show anything for aac. Also it seems to detect .ogg Vorbis files, but cannot play them.
Anyway, just confirms that MP3 is the damn standard everywhere :)...