Thank you very much for the new version.
... so conceivably it has adversely influenced recent fine-tuning of the -3 quality preset settings......
Quote from: Nick.C on 03 January, 2008, 01:11:47 PM... so conceivably it has adversely influenced recent fine-tuning of the -3 quality preset settings......What is your opinion on that? Do you think we can try again to arrive at a lower average bitrate? Or should we be more cautious?
I see, clipping was not detected on -ve occasion, and thus the clipping prevention strategy was not triggered.With my personal kind of thinking this is not a sufficient reason for going less defensive, but I see you'ld like to have average bitrate a bit lower, and maybe that's true for other potential users as well.Well, there is no strict reason to have the -nts defaults where they are right now. I personally am happy with them, but I'm happy too with other defaults especially as we've always wanted to have -nts as a major option.I think we should encourage users to use other -nts value than the defaults, and the defaults themselves can be like that though better not at the extreme edges.With -3 for instance I think an -nts usage from -nts 0 to -nts 10 is okay, with -nts 0 playing it very safe, and -nts 10 allowing for potential but very minor audible deviations from the original.With -1 any -nts value >=0 makes sense, and everybody can choose the security margin he likes.For -2 any -nts value <= 10 is useful (though a large positive value may be more adequate together with -3).Maybe we should try to write something like this in the wiki (shall I do it in case I'm allowed to?).
...Feel free to edit the wiki article - you are a major contributor to the project after all....
Done, but can you please look it up and correct errors as I'm not a native English speaker.BTW, I've moved the player comparison link to the codecs section, and added a remark on Rockbox supporting FLAC and wavPack. Guess the codecs section is the more appropriate place especially as the preset section got a bit fatter by my contribution.
lossyWAV beta v0.6.1 now appended to post #1 of this thread.
Is that not the FLAC default? Cheers,David.
I was playing about with FLAC settings on my processed 53 sample set and found the following (all at -b 512):-0; 45415797B; 3.89s-1; 46004820B; 4.89s-2; 44305745B; 4.75s-3; 41716318B; 4.89s-4; 42151483B; 5.45s-5; 40646358B; 8.20s-6; 40637026B; 9.03s-7; 40497737B; 29.49s-8; 40305661B; 38.44s-3 -m -e -r 2; 40894438B; 13.52sIs it just me, my sample set or my PC - but does -5 seem to be the sweet spot for encoding?
Nick,This is looking really good. Do you feel you're close to a release candidate yet? It seems that the code works well enough, and it's just a case of settling the command line options and documentation.Would you be able to find time to explain the algorithm as it currently stands? Or should I just read the code Obviously I'm most interested in the changes, but other people might want a full overview without reading 29 pages!Cheers,David.
lFLCDrop Change Log:v22.214.171.124- added correction file settings- added custom encoding settinglFLC.bat Change Log:v126.96.36.199- added flac decoding support- added correction file encoding support- added custom settings section- improved temp file handling
I had an idea, it might already be this way. I didn't check. But if the correction file was encoded with the bits reversed (16=1/15=2/etc) for whatever bit-depth needed, wouldn't lossless codecs encode that more efficiently? Since it's not really an audio file someone would use directly, that makes sense for starters, and it shouldn't complicate things if lossyWAV-compliant decoding were ever to be built into any lossless decoders. And there should be practically no speed hit at all.
lFLC.bat Change Log:v188.8.131.52- fixed drive letter bug
... look for FFT's where all the input values are zero ...
carpman, check your system-drive for the directory that was created of the same path as the files you were trying to encode. You should find the flac files and can delete them.
Quote from: Nick.C on 06 January, 2008, 04:58:54 PM... look for FFT's where all the input values are zero ...The input values to the FFT: isn't that the wave samples of a block?
I see. You look at the codec blocks' subblocks formed by the particular FFTs and ignore the FFT result (not doing the FFT) if the subblock contains silence.Sounds reasonable though I think for a silent passage only the first and last block (containing partial silence) will take profit of this mechanism as the main silence part affects entire blocks.I'm not quite sure about the window function. Can the windowing bring FFT input to zero though it's not zero in the wave input? I guess it doesn't but I'm not sure.