Sample 3 - Sine Wave - A440 (generated in Cool Edit)RG = -11.43 dBOriginal FLAC -5 (318 kbps)-q 10 -b 512 (363)-q 7.5 -b 512 (363)-q 5.0 -b 512 (363)-q 2.5 -b 512 (363)-q 0 -b 512 (352)-q 7.5 -b 4096 (296)-q 5.0 -b 4096 (296)-q 2.5 -b 4096 (296)Should I be getting identical bitrates to the original, or is the point that regardless of -q setting lossyWAV is not compromising quality (except at -q0, but hey)? C.
If you have Cool Edit, you can simply load the original .wav and the .lossy.wav and subtract one from the other (mix paste, 100%, invert) to see if there is any difference at all. Or use the foobar2k wave comparator. Or ask lossyWAV how many bits it's removing.Cheers,David.
It would be interesting to see the bitrate of original FLAC -b 4096 and the identical compression option you used with lossyWAV (I only guess you use -5 too). As the lossyWAV bitrate is the same with -q 2.5 to -q 7.5 I expect original FLAC will get close to this bitrate when using -b 4096 as with lossyWAV.
Should I be getting identical bitrates to the original, or is the point that regardless of -q setting lossyWAV is not compromising quality (except at -q0, but hey)?
Did a mix-paste in Cool Edit, and just ran a bit compare in foobar: No differences in decoded data found.Yet in foobar, bitrates are different: FLAC Original -b 4096 = 318LossyFLAC -b 4096 -q 5 = 296Anyway, the point is made and to be honest I'm just happy that lossyWAV is very careful indeed with the data, and thus it's fine to use for archiving and using as transcode source. Thanks Dynamic for the explanation. C.
I'll be releasing 1.1.0 final tomorrow night - but I wonder which of the more advanced options included for developmental purposes post 1.0.0b should be removed?My guess is that --limit should stay but noone seems to be using --highskew. --blocksize is also not necessarily a good idea to keep as it may confuse users as it may be better to keep it at 512 samples throughout.I've been sorting out the logfile mechanism - it will no longer crash with two or more foobar2000 transcoding threads. Also, I've expanded on --bitdist - now renamed as --blockdist and supplemented by --sampledist which both give information about the block / sample distribution of lsb's and msb's. This will also be written to a logfile.For the logfile when used with STDIN, I have implemented a --stdinname parameter which is followed by the name which the user wishes to be displayed on the console and also written to the log.Any suggestions, likes, dislikes, etc will be very much appreciated.
I'll be releasing 1.1.0 final tomorrow night ...
... but I wonder which of the more advanced options included for developmental purposes post 1.0.0b should be removed? ...
IMO most of the advanced options should be removed in a final release.--highskew, --blocksize as you think, but if it is up to me I would always make the last beta version available, and keep the advanced options there, but remove the advanced options from the final verison with very few exceptions.Valuable exceptions IMO are -q, --scale, -s.The problems with many of the advanced options is also that an average user can't understand them, and a really useful precise description will probably offend many users.The other problem is the mere number of advanced options which at the end of the day has more of a negative effect than a positive one.So IMO there should be a high threshold, and an advanced option should have a very promising effect at least to some people in order to justify a specific advanced option within the final version.The situation is different with beta versions where there are users which want to be a bit experimental.So for the final version I'd even prefer not to have the --noclips option any more.
...To confirm: --fft32, --analyses, --highskew, --blocksize, --minbits, --noclips & --wine will all be removed for the release of 1.1.0.