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.
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.0that 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
Last post by knik -
220.127.116.11 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:
Last post by Gehirnmaehung -
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!
Perhaps the embedded album art is too big.
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?
Last post by Porcus -
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 (https://msdn.microsoft.com/en-us/library/windows/hardware/dn653308.aspx - 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.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.
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.
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.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.)