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: foobar2000 v2.0 bugs (Read 129501 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: foobar2000 v2.0 bugs

Reply #525
Signal path is hardcoded. audio_sample type is defined to float32 for 32bit foobar2000, 64bit for foobar2000. It can't be changed at runtime.

In 64-bit foobar2000:
All decoders output float64 audio.
All DSPs take and produce float64 audio (what they use internally is another story).
All outputs take float64 audio (though all have to downconvert it as no real life device accepts float64 data).

If I changed these audio_sample definitions, it would produce a foobar2000 build that can't run any existing components, because audio_sample format is an essential part of all audio related component interfaces.
That is why I chose to change it for foobar2000 64-bit, since all components needed rebuilding anyway. I'm not entirely sure if it makes sense, but I'll never have a chance to change it again.
Microsoft Windows: We can't script here, this is bat country.

Re: foobar2000 v2.0 bugs

Reply #526
I've tested latest beta foobar v2.0 x64 with ASIO driver 2.2 x64
At last foobar can output 32bit files correct and bit-perfect!!!

There is only one problem, there is no option to choose 32bit ASIO devices now. Only 64bit ASIO drivers supported.
On v1.6.16 there was support for both driver versions. And we have to wait for all plugins to be updated to x64. It will take a long time i think.

As far as i remember long ago there was foobar2000 0.8.3 with 64bit internal processing and 32bit ASIO output with Otachan plugin. And foobar2000 0.8.3 was a 32bit prorgam. It was fenomenal for that time! Thank you Peter.

Is it possible to implement 64bit internal processing for 32bit versions v1.6.x and v2.0 too? (at least just for volume control)

Re: foobar2000 v2.0 bugs

Reply #527
Signal path is hardcoded. audio_sample type is defined to float32 for 32bit foobar2000, 64bit for foobar2000. It can't be changed at runtime.

In 64-bit foobar2000:
All decoders output float64 audio.
All DSPs take and produce float64 audio (what they use internally is another story).
All outputs take float64 audio (though all have to downconvert it as no real life device accepts float64 data).

If I changed these audio_sample definitions, it would produce a foobar2000 build that can't run any existing components, because audio_sample format is an essential part of all audio related component interfaces.
That is why I chose to change it for foobar2000 64-bit, since all components needed rebuilding anyway. I'm not entirely sure if it makes sense, but I'll never have a chance to change it again.

Hi @Peter,
I just tested foobar 2 beta 27 64bit and tried to convert 32 bit integer wavpack and flac to flac or wav or wavpack and I got either error or 32 bit float. So is it possible to convert to 32 integer, if so how, if not will it be in the future?
I tried flac 1.4.2, ffmpeg6.0 and wavpack 5.6. Errors or 32 floats.
DBpoweramp does it, foobar does not.

Re: foobar2000 v2.0 bugs

Reply #528
I'm on Beta 27 now and it seems like there is a regression - the popping and lingering audio from the previous track upon manually changing tracks is back even though I have "Fast DSP reset when cycling tracks manually" off.
The issue persists in Beta 28.

**Edit**
The issue seems to go away when I turn off "Enable smooth seeking, pause and volume changes". This is a really nice feature though, and I would really prefer to leave it on.
Think millionaire, but with cannons.

 

Re: foobar2000 v2.0 bugs

Reply #529
I just verified that v2.0 beta 24 doesn't exhibit this behavior. I am using 32-bit Portable, if that matters.
Think millionaire, but with cannons.

Re: foobar2000 v2.0 bugs

Reply #530
I just verified that v2.0 beta 24 doesn't exhibit this behavior. I am using 32-bit Portable, if that matters.
Thanks, looking into it, though I can't recreate it so far.

What about beta 25 and 26?
https://www.foobar2000.org/getfile/foobar2000_v2.0_beta_25.exe
https://www.foobar2000.org/getfile/foobar2000_v2.0_beta_26.exe

What exact audio device are you using?
ASIO etc perhaps?
Microsoft Windows: We can't script here, this is bat country.

Re: foobar2000 v2.0 bugs

Reply #531
I've tested foobar v2.0 for bitperfect playback. RME ADI-2 Pro FS DAC has a special internal test for it, and it shows on display if the output of player is correct or not. All settings are default. Volume is 0dB. I checked all possible combinations with 3 different DACS i have
Maybe it will be useful for somebody.

Re: foobar2000 v2.0 bugs

Reply #532
Default: Primay Sound Driver - not bit perfect at all !
Default: RME DAC - not bit perfect at all !
Default: RME DAC (exclusive) - Exclusive output overrides=off Use event=on in Advanced menu (Default foobar options) - very distorted audio!!!
Default: RME DAC (exclusive) - Exclusive output overrides=off Use event=off in Advanced menu - very distorted audio!!!
Default: RME DAC (exclusive) - Exclusive output overrides=on Use event=on in Advanced menu - very distorted audio!!!
Default: RME DAC (exclusive) - Exclusive output overrides=on Use event=off in Advanced menu  16bit output 16bit file - bit perfect 16bit
Default: RME DAC (exclusive) - Exclusive output overrides=on Use event=off in Advanced menu  16bit output 24bit file - bit perfect (but 16bit)
Default: RME DAC (exclusive) - Exclusive output overrides=on Use event=off in Advanced menu  24bit output 24bit file - bit perfect 24bit
Default: RME DAC (exclusive) - Exclusive output overrides=on Use event=off in Advanced menu  24bit output 32bit file - bit perfect (16bit, not 24bit)

Default: RME DAC (exclusive) - Exclusive output overrides=on Use event=off in Advanced menu  32bit output 32bit file - bit perfect 32bit
ASIO: RME DAC - bit perfect (with all samling rates and bitrates)

So there is only 2 good options:
1. ASIO output
2. WASAPI (exclusive) with special settings: 32bit output, Exclusive output overrides=on, Use event=off in Advanced menu


Peter, if it is impossible to fix all exclusive modes, maybe just set my settings in Advanced menu by default in foobar?

Re: foobar2000 v2.0 bugs

Reply #533
fix all exclusive modes, maybe just set my settings in Advanced menu by default in foobar?
Default settings are default because they work for most cases. Bu not for all cases. And this is why these settings are allowed to be changed by user.

Re: foobar2000 v2.0 bugs

Reply #534
fix all exclusive modes, maybe just set my settings in Advanced menu by default in foobar?
Default settings are default because they work for most cases. Bu not for all cases. And this is why these settings are allowed to be changed by user.

I mean not to use WASAPI exlcusive output by default, but to change it default settings in Advanced menu to working ones.

You write that the default WASAPI exlusive settings in foobar work for most cases. I've tested many souncards and DACs with them, and none of them are usable. The settings that i recommend are useable for most cases.

WASAPI (exclusive) settings: Exclusive output overrides=on, Use event=off in Advanced menu

Re: foobar2000 v2.0 bugs

Reply #535
fix all exclusive modes, maybe just set my settings in Advanced menu by default in foobar?
Default settings are default because they work for most cases. Bu not for all cases. And this is why these settings are allowed to be changed by user.

I mean not to use WASAPI exlcusive output by default, but to change it default settings in Advanced menu to working ones.

You write that the default WASAPI exlusive settings in foobar work for most cases. I've tested many souncards and DACs with them, and none of them are usable. The settings that i recommend are useable for most cases.

WASAPI (exclusive) settings: Exclusive output overrides=on, Use event=off in Advanced menu

hmm..
 I have Realtek UAD driver v6.0.9492.1 for said audio chipset..
- Realtek® ALC1220A 8-Channel High Definition Audio CODEC for my ASUS PRIME x570-PRO latest BIOS v4602.
for devices I always point to my Realtek (speakers) output and never use the exclusive mode... hmm...
never had any issues as far as I can tell...
but best of luck figuring this out,, or a bug fix..

but my point is, is your drivers up to date?

Re: foobar2000 v2.0 bugs

Reply #536
I've showed with my tests, that the benefit of using WASAPI exclusive or ASIO is only if you want to have bi-perfect playback, i.e. ideal quality as it was recorded.

The default mode that everyone and you uses is all purpose for everething in Windows. But it is not bit-perfect. And of cource this default mode can't switch the sample rate of your souncard. By default windows configure every souncard samplerate at 48kHz and it is fixed for every program that you use. But if you play music files from foobar wich are mostly 44.1kHz, then windows will resamle it from 44.1kHz to default 48kHz, and so the sound will become even worse.

WASAPI exclusive mode in foobar can change this samplerate, and the sound didn't change and that's why it is perfect.
You can check it in settings of your soundcard during playback

Re: foobar2000 v2.0 bugs

Reply #537
I will test and possibly zip my portable install for you when I'm able. Thanks.
Think millionaire, but with cannons.

Re: foobar2000 v2.0 bugs

Reply #538
I just verified that v2.0 beta 24 doesn't exhibit this behavior. I am using 32-bit Portable, if that matters.
Thanks, looking into it, though I can't recreate it so far.

What about beta 25 and 26?
https://www.foobar2000.org/getfile/foobar2000_v2.0_beta_25.exe
https://www.foobar2000.org/getfile/foobar2000_v2.0_beta_26.exe

What exact audio device are you using?
ASIO etc perhaps?

Sorry for the delay. Difficult days. Anyway...
Same settings were used in all cases. I verified that the behavior only happens with "Enable smooth seeking, pause and volume changes" on (50ms for all except 0ms for fade in on manual track change) in conjunction with certain DSPs (Stereo Convolver and/or MathAudio Headphone EQ will each cause the bug). Audio devices were a Schiit Modius in exclusive mode 24-bit and also my onboard realtek device non-exclusive. Both devices exhibited the behavior. If you want, I can 7z archive my foobar portable install and send it to you with sample tracks which tend to make the bug very audible.

*Edit*
Just did some more tests. Checked and made sure some more settings were the same.
Behavior is there in 24, 25, 26, 27, and 28.
I guess that means I need to test with older versions.
Think millionaire, but with cannons.

Re: foobar2000 v2.0 bugs

Reply #539
More testing. The bug is present even in beta 20. Same rules apply - turning off "Enable smooth seeking, pause and volume changes" will make it stop, or removing the identified DSPs.
One more test for now. The bug is there even in v1.6.10. I guess it's not a new bug, but a bad interaction between the identified DSPs and smooth seeking.

*Final edit*
I believe my confusion came from the audio devices with "DEFAULT" at the beginning automatically disabling smooth seeking, which prevented the bug in some cases.

Thank you.

*Even more final edit*
On a whim, I decided to also test with 0ms for both fade in and fade out on manual track change, and also 50ms for both. The bug persists in both cases.
Think millionaire, but with cannons.

Re: foobar2000 v2.0 bugs

Reply #540
I tried a fresh installation, and it didn't have the bug until I also installed and added foo_dsp_stereoconv and Resampler (SRC).

To reproduce the bug:

1. Install foobar2000 beta 28 portable (or really any version even as far back as 1.6.10. I've only tried with portable.)

2. Install these components
Stereo Convolver (linked) (MathAudio Headphone EQ seems to work as well, but I haven't tested it as thoroughly)
https://foobar.hyv.fi/2.0/?view=foo_dsp_stereoconv
Resampler SRC:
https://www.foobar2000.org/components/view/foo_dsp_src_resampler

3. Add the two DSPs in order (screenshot included)
Stereo Convolver
Resampler (SRC)

4. Configure Resampler (SRC) with target "Upsample 4x" and Mode "Best Sinc Interpolator". Stereo Convolver can use the default settings and still reproduce the bug, though I normally use different impulses.
*note - My test tracks were both 44100Hz 16-bit and very loud (almost reaching -0dB)

5. Turn On "Enable smooth seeking, pause and volume changes" (I use 50ms for all except fade in on manual track change, but it doesn't seem to matter)

6. Manually change between tracks.

The bug doesn't happen on every manual track change, but it is fairly frequent, and it occurs much more often - almost every time - when more DSPs are added. I realize this is pretty specific and these components are not yours (Peter), but it is a real setup I use, and it still only causes the bug when smooth seeking is enabled. Thank you for reading.
Think millionaire, but with cannons.

Re: foobar2000 v2.0 bugs

Reply #541
Converter in foobar v2.0 have 3 issues:

1. I have playlist with 32bit int files in wav or flac. If i want to export it to 32bit int wav without bitdepth change, just format conversion, there is no such option. Only 32bit, but it's floating. So the bits in files will be changed. Maybe it's wise to add such an option to choose 32bit or 32bit-float?
2. Even if i press convert, converter doesn't remind of lossy bits operation. I checked foobar v1.6.16, it does remind
3. After conversion there is annoying window 'Converter output'. And there is no option to disable it

Re: foobar2000 v2.0 bugs

Reply #542
I tried a fresh installation, and it didn't have the bug until I also installed and added foo_dsp_stereoconv and Resampler (SRC).

(...)
Thanks for the details, I'm investigating mitigation techniques for this.

Possible workarounds:
  • Increase output buffer length - smooth mode starts playing after 1/4th of the buffer is ready, that would be 250ms with defaults; if more audio audio doesn't arrive in time after that, glitch happens. Try 5000ms output buffer instead of the default 1000ms please.
  • Change automatic resampling behavior - by default, SSRC is used to resample played audio to match Windows Mixer sample rate. SSRC which isn't very CPU efficient, you can set Advanced Preferences / Tools / Automatic Resampling to "Resampler (RetroArch)", without the quotation marks, or to any other name of DSP which you wish to be used for implicit resampling.
Please report if either of the above helps.
Microsoft Windows: We can't script here, this is bat country.

Re: foobar2000 v2.0 bugs

Reply #543
Peter, if it is impossible to fix all exclusive modes, maybe just set my settings in Advanced menu by default in foobar?
Is the device name exactly spelled "RME DAC" ?
I'll add it to internal workarounds list so you no longer need to change advanced settings.
Microsoft Windows: We can't script here, this is bat country.

Re: foobar2000 v2.0 bugs

Reply #544
Converter in foobar v2.0 have 3 issues:

1. I have playlist with 32bit int files in wav or flac. If i want to export it to 32bit int wav without bitdepth change, just format conversion, there is no such option. Only 32bit, but it's floating. So the bits in files will be changed. Maybe it's wise to add such an option to choose 32bit or 32bit-float?
2. Even if i press convert, converter doesn't remind of lossy bits operation. I checked foobar v1.6.16, it does remind
3. After conversion there is annoying window 'Converter output'. And there is no option to disable it
1 + 2, looks like an oversight, fixing. Thanks for reporting.
3. Checkbox for this is shown in conversion progress dialog, I guess it's hard to see or click if conversion finishes near instantly.
Microsoft Windows: We can't script here, this is bat country.

Re: foobar2000 v2.0 bugs

Reply #545
PS
I'm still waiting for someone to enlighten me about legitimate purposes of 32bit integer audio. I can't think of any.
Microsoft Windows: We can't script here, this is bat country.

Re: foobar2000 v2.0 bugs

Reply #546
Possible workarounds:
  • Increase output buffer length - smooth mode starts playing after 1/4th of the buffer is ready, that would be 250ms with defaults; if more audio audio doesn't arrive in time after that, glitch happens. Try 5000ms output buffer instead of the default 1000ms please.
  • Change automatic resampling behavior - by default, SSRC is used to resample played audio to match Windows Mixer sample rate. SSRC which isn't very CPU efficient, you can set Advanced Preferences / Tools / Automatic Resampling to "Resampler (RetroArch)", without the quotation marks, or to any other name of DSP which you wish to be used for implicit resampling.
Please report if either of the above helps.
They didn't help. Buffer length didn't seem to affect it at all.
Regarding the resampler I've been using - I've been upsampling to 176400Hz for final output because I recall seeing graphs which showed the DAC handled it more cleanly, however I can't claim that for certain because I can't find said graphs anymore and I don't think I could tell a difference either way. I think for now I'm just going to remove that resampler from the DSP chain and listen at 44100Hz. It's also important to note that this DAC was in exclusive mode, so I don't think the automatic resampler would have been activated during my tests except on the other audio device. Oddly, I use the same resampler earlier in the chain and it never causes a problem unless it comes after the Stereo Convolver or other offending component.
Think millionaire, but with cannons.

Re: foobar2000 v2.0 bugs

Reply #547
Not sure if this is bug of feature or neither, but anyway:

* Fair enough: If I make changes to a file outside fb2k - keeping time stamp - fb2k does not "see" the change unless I instruct to reload info.
* But: If I even play the file, fb2k does not update. Any reason not to? Obviously it has to read the file (and the files in question are FLAC, with metadata at the beginning.)

Re: foobar2000 v2.0 bugs

Reply #548
PS
I'm still waiting for someone to enlighten me about legitimate purposes of 32bit integer audio. I can't think of any.

There are 32 bit int audio files (maybe not many but still there are) so some people want to use them. If we can play and convert 16bit and 24 bit files properly why make it impossible to play and convert 32 bit int files properly? It was "technically" impossible in 32 bit FB but in 64 bit FB it should be normal - out-of-the-box thing. To be honest I thought that this is the main reason to implement 64 bit FB. I do not need to know how many people and why want to use it. If it will be implemented I surely will use it. Someone said earlier that his DAC can "see" 32bit int file so why not to let him use this feature (and again: I do not need to know why he needs it or does it make any audible difference, it just is possible and FB2.0 64 bit can do it technically, so why not?) If there is any reason to deliberately block such a feature why not also block 24 bit or 16 bit? Or anything else? I do not want to offend you (I am really grateful for your hard work on this program) and I do not know anything about programming - maybe it is very hard to implement such a feature - if so, probably most users will understand why it is not implemented but if it is just a matter of "justification" of someones need to use 32 bit int then I still hope that one day you will implement, even without legitimate purpose.  Especcially that another program of yours can do it already. Once again - big thankyou for your program.

Re: foobar2000 v2.0 bugs

Reply #549
If there is any reason to deliberately block such a feature
I don't think "looks like an oversight, fixing" looks like it was deliberate.

Apart from that, I'd say you are right.
Stupid: 32-bit integer
Bad: Violating the "lossless is lossless" maxime.

Others are providing "Stupid", fb2k need not behave "Bad". And it looks like it will be fixed.