that was my hunch too, that for noisy samples you might get better results with shorter blocks.clever idea. in practice I think the file should also be tagged with the preprocessing parameters so it could be identified without analyzing all the frames.
So ... basically you are applying a variable or 'gliding' noise gate if I understood correctly?
Please call your variant LFLAC or something other than FLAC please to avoid confusion with older decoders/hardware implementations which likely won't support any lossy variant. Thanks!
The idea is simple: lossless codecs use a lot of bits coding the difference between their prediction, and the actual signal. The more complex (hence, unpredictable) the signal, the more bits this takes up. However, the more complex the signal, the more "noise like" it often is. It's seems silly spending all these bits carefully coding noise / randomness.So, why not find the noise floor, and dump everything below it?
This sounds like something that could be achieved through collaboration with FLAC's developer - add a command to FLAC.EXE to select a "quality" which might equate to how aggressive the algorithm is and output to a FLAC file.
BTW: FLAC's default blocksize is 4608, isn't it? The encoder's blocksize should match the preprocessor's blocksize so no "wasted bits" are coded.
Also, for noisy transients it's good to be able to quickly change "wasted_bits" which suggests merging preprocessor + encoder into one program that uses variable length blocks. As a matter of fact I recently (couple of weeks ago) read the FLAC file format spec again to check wheter I should give it a try ...
Now, if a Foobar based transcoder could be implemented, I could drop OGG and use the LFAC pre-processor to shrink my FLAC-for-iPAQ files..... (I just found the GSPlayer gspflac.dll file )
Are you saying what I've done is equivalent to what you describe? Or better/worse? Or didn't you look at what I'd done?
Quote from: SebastianG on 13 June, 2007, 10:23:44 AMAs a matter of fact I recently (couple of weeks ago) read the FLAC file format spec again to check wheter I should give it a try ...I've been working on supporting variable blocksize properly; currently thespec is ambiguous in some cases... stay tuned.
As a matter of fact I recently (couple of weeks ago) read the FLAC file format spec again to check wheter I should give it a try ...