Skip to main content

Recent Posts

When I'm skipping a song (from within the default f2k control button: next) the stub image is shown for about 500ms.
So it takes over 500ms to skip to the next song on your setup?
I've set the delay to 200ms... I guess I just make this delay configurable to be able to handle slower setups.
3rd Party Plugins - (fb2k) / Re: foobar2000 DeskBand Controls
Last post by fuffi -
Thank you,
the changelog sounds great!
Link detection works nice! Its now so simple to check out the, i.e. WWW-tag or discoGS information!

  * Version 3.5.0
  - Fixed stub image appearing for a moment when switching tracks.
that seems not to be changed.
When I'm skipping a song (from within the default f2k control button: next) the stub image is shown for about 500ms.

I've tested with old path to the stub E:\m\p\f2k\foo_httpcontrol_data\kevo\nocover.jpg
and also a new relative oath: .\foo_httpcontrol_data\kevo\nocover.jpg
3 is very fast, to the point I'm running out of the legend space!
I'm afraid I have a plan to speed it up even more, like several percent. Maybe you could remove faac-1.28 and put legend to the bottom.

Anyway, new bugfix release:

i used the same configuration for many years now, some rather old version of EAC with REACT. On my new PC i cant install this combination of software and i have to move on to newer versions.
That new version doesnt work yet, the FLAC seems to be different from my old setup, and i cant figure out why.

If i am not mistaken, there arent any new versions of REACT, right? At least i cant find them ... if there are, i will surely give it a try!

What i did instead was installing the latest EAC and just trying to rip CDs, comparing them to the files i already have, with the goal to find a configuration that works the same as the old one (the automation-aspect of REACT will be adressed later, for the first step i want to reproduce the old files).
I rip CDs as whole album, to get one FLAC file with the corresponding cuesheet. I want the gaps to be before the next track (index 00) and i use album-replaygain.

After some toying around i managed to produce the files, but something seems to be wrong. I play them with foobar, and foobar displays just the second track (for every CD i tried), but when i play it, it plays the whole CD starting with track 1.  It should display every track individually, obv ;)
At first i thought the problem might be the cuesheet, so i compared them, but they are roughly the same (replaygain still missing, and an empty "composer" variable). Then i copied an old cue to use with the new flac, which didnt change a thing.
Then i used an old flac (ripped with my old setup) with a new cue, and voila - it works as intended.

Now my question is: what setting might be wrong, to produce flacs that behace like that? How can i compare them to one another? Why is always only the second track displayed in foobar?

I hope someone can point me in the right direction :)

Thanks in advance!
FLAC / Re: Issues with playing FLAC files in a Mazda
Last post by spoon -
Perhaps the embedded album art is too big.
Polls / Re: Where do you get your music from?
Last post by The Seeker -
I just switched from Spotify to Apple Music again last month.

I've been tossing up between these two services; have you found one to be superior to the other?
Thanks for the warning. And thanks to ReplayGain and fb2k's preamp option that turns down files w/o RG info ...

There could be a lot of different signals in a WAVE file ( - date says 2007, but a version was around before y2k), but I don't think I have seen music published as anything but 16-bits integer, 24-bits integer, whatever-32-bits-that-WavPack-can-contain - and one single IMA ADPCM.
I have experimented with creating a WavPack DSD image with embedded cuesheet, and they play great (and gapless) in the latest Foobar2000, both stereo and 5.1 multichannel versions! I used the program sacd_extract (on Linux) to extract the audio from an ISO as a DFF “edit master”, which is basically a whole-album DFF file with a separate cuesheet. I also used the option to decompress DST. Then I compressed that with WavPack, embedding the cuesheet, and also some cover artwork that I downloaded separately.

At first Foobar2000 would not recognize the cuesheet and I was afraid that this wasn't going to be easy, but then I discovered that the cuesheet started with a UTF-8 BOM marker (0xEF, 0xBB, 0xBF) that WavPack was not removing and Foobar2000 was not accepting. I deleted that with a text editor and it worked perfectly. It might be possible to just use Foobar2000 to embed the cuesheet, but I didn't try that.

I'll fix WavPack to correctly interpret and ignore that BOM marker, and then this should work for those who would like to have this option.

Hi Bryant, could you please show me how to create WavPack DSD image with cuesheet embedded? I am looking for a solution to convert multiple DSF files into a multi-track cuesheet embedded WavPack image to be specific.
General - (fb2k) / Re: Making foobar close to windows tray
Last post by eahm -
Nah, I was just suggesting what mIRC does but thinking about it, it can be useful if you leave the PC mixing at a party so no one changes anything.

Yes, you could do Win + L and lock the screen but Windows may bypass the app' settings and it go to sleep if not disabled, people forget to do that.
General Audio / Re: 32-bit floating-point (WAV) files "in the wild"
Last post by jsdyson -
A very horrible thing with float 32 file is they can be encoded in different "normalized" fashions. If the decoder misinterpret the format, the result will be horrible full scale square wave-ish like crap which may destroy your equipment. I experienced this nightmare several times, sometimes in foobar2000, sometimes in Audition.

Of course, in DAWs if people find the decoded waveform looks like crap, they won't hit the play button, but that's not the case with typical audio players.
oh my!!!   Most of the files that I have dealt with are +-1.0 floating point, but I do know that it is theoretically possible to sent out files with bigger numbers.  I always believed that +-1.0 floating point is the same as +-32767  for 16 bit signed -- and so be it...  So, you have seen different?   But of course, invalid files with >+-1.0 (assumed that they were invalid) should be clipped and/or flagged.   In between running my Unix pipelines, I do (incorrectly, I believe) SOMETIMES during my experiments,  take advantage of being able to deal with greater than normal floating point values.   For example, I might have an expander whose output might peak at +-2.828 (just as an example) due to exceptional material, but then future normalization stages will fix it.  On the other hand, 'sox' will complain about such files, and probably should process the file if the results are correctly normalized,  or MAYBE SHOULD BASED UPON COMMAND LINE FLAGS simply bounce the file somehow?.

Your point about nonstandard floating point values is definitely a valid issue, however.  (By the way, the term normalized/un-normalized has a specific meaning the the floating point realm -- when the term different 'normalization' was used -- I assumed being able to handle differing/odd ranges of values, right?)
So, to me, it seems like the FP format  should be standardized, or avoided for interchange.  I suspect that for most (all) PRACTICAL purposes, the signed 24 bit should be sufficient, but wonder if it also has such scaling issues?  (I use 24bit only so that I can use flac with reasonably high resolution.)

John Dyson