Last post by Gehirnmaehung -
That's a good hint, i will look into that! I did not modify the command line parameters the new EAC uses, i thought they weren't relevant in my case.
With GCC compiler you need to use ./configure --enable-intrinsics for opuslib and --enable-sse for opustools. Without these settings you lose 20% encoding speed and 50% decoding speed. Note that the --enable-sse flag means the compiled binaries don't work on old CPUs that lack those instructions.
I think it's useful to think of foobar2000's *.fpl "playlists" more as containers. Since you can load entire (and multiple) playlists into them. So for example if you want to fix a certain order, you can have a permanent foobar2000 playlist called "Whatever", and simply load (File > Add files ...) a "classical-strict-order.m3u" playlist into it. You can make all the changes to the order you want in the "whatever.fpl" container - it won't have any effect on the classical-strict-order.m3u playlist until you save it (right click playlist tab > save as ...").
That's why with foobar2000 there's really no need to have a vast array of static playlists (always on display). Since loading files into the "fpl" containers is easy and quick, You can keep them loaded for as long as you like, until you decide to flush the static container and use it for something else - the "classical-strict-order.m3u" won't get overwritten by foobar2000 (unless you manually instruct it to).
That's the way I use foobar2000 anyway. It seems designed for this kind of behaviour.
See this pic: - you'll notice all the foobar2000 playlists have names like Current, Temp, Random etc ... those "playlists" (containers) are used to create, load, re-order, edit, save many m3u playlists stored outside of the foobar2000 directory structure (......\foobar2000\playlists-v1.3\*.fpl).
Unless you need to encode a lot of music very quickly I would use the standard lame builds. The difference in speed is not that compelling on modern hardware.
Last post by Nick.C -
David made a change to WavPack to permit the storage of floating point audio using the same compression method as for integer audio (around the time I was developing TransPCM - which can output Float16 audio from several different inputs).
For Float16, I made use of the full range, i.e. ±65504 at the top end to ±5.96046E-08 as the minimum subnormal, giving a range of 1,098,975,582,421:1 (or approximately 40 bits) with up to 11 significant bits.
One other option is to just let foo_wave_seekbar finish scanning it's current to-do list and then force a scan of the rest of the DST files sometime when you don't really need the computer for a while so that it doesn't have do it the first time you play a DST. I usually do a seekbar scan of all DSD files when I first add a new SACD or album to my library...
ran a new cable outside the wall, with a bit of dressing/channel mount to make it look nice?
*Run*, not ran
You're even more confused than you think. LAME != FLAC. One's an MP3 encoder, lossy by definition, the other one's a lossless codec.
Aren't i an idiot?! Shows you what two hours of sleep will do! I meant to say the rarewares lame3.100-64 or the tmkk build.
Sorry about that!
@kode54 Thanks for the detailed response.