When it was up to introducing our current clipping prevention scheme I searched hard for clipped tracks with the result that my collection has clipping next to nothing.

IMO we should stick to your suggestion for -3. After all clipping exists. But I think my clipping album is an extreme case of clipping, and AlexB's sample is more representative for clipped tracks.
Because of this and the fact that clipping is very rare I suggest to allow only 1 clipped sample in a block for -3, and keep the clipping prevention scheme in full action with -2.

I would certainly agree that -1 should have full clipping prevention. For -2, maybe 1 clip per channel per codec_block would be acceptable. For -3, 2 clips per channel per codec_block seems to work well ... we just have to agree amongst ourselves as to the exact number of (rounded down) clips acceptable for each quality preset.

Well to me the pretty rare event of clipping is an argument not to circumvent the clipping protection scheme with -2 and keep -2 in a 'pure' form. But we shouldn't continue this forever, so do go ahead with your favorite choice. I also don't think giving away clipping protection for 1 sample per channel and block will be audible.

Thank you Nick, especially for -noclips.
Can you tell a bit about the new window function and the noise constants? Are these changes conservative, or is it necessary to do some testing?

From my understanding we need more than 1 FFT because for getting a good temporal resolution (catching transients) we need a rather short FFT, and for a good frequency resolution in the low to medium frequency range we need a long FFT (for the very high frequency range the short FFT should be sufficient).

From this and from practical results I don't see why we should have more than 2 FFTs. It's okay to have an addtional FFT for safety reasons when going from -3 to -2, and from -2 to -1, but I don't see why we should go beyond that.

Sorry for being so negative towards your recents suggestions. I see you're eager to get further improvements the one or other way.
To me personally I think things are very good and don't need refinement as long as no issues come up in practice.

The only thing I personally would like to have consideration one last time is the coverage of the FFT windows of the 1024 sample FFT over the block.
We have a different sight on this as you feel the need that there is a 50% overlap of FFT analyses between adjacent blocks. I don't see any overlapping necessary for the blocks, and I think your consideration is based on one of 2Bdecided's remarks but I beleive this is a misunderstanding. Bits to remove decision in my understanding is not a global decision, not a block-overlapping decision, IMO not even a block-orientated decision (but I think the latter has no practical impact). IMO we can assign to each singular sample a number of bits to remove based on the analysis of those FFT windows where the specific sample has a contribution.
Block consideration comes in as the lowest number of bits to remove (per sample) must be chosen in order to assign a bits to remove number to the block. Moreover it's useful to base the FFT window partitioning based on the block. What's necessary is a good overlapping of the FFTs in the block under consideration. According to 2Bdecided the overlapping of the FFT windows (within the block!) should be 50% or more. We had a discussion before from which I thought we have an overlapping of 5/8 but IIRC this is not practice currently.
My suggestion once was that in order to have the overlapping not to go far into neighboring blocks as their samples have nothing to do with the block under consideration, and I suggested to have the centre point of the most outward FFT windows a little bit within the block. 2Bdecided preferred the edge position because of a good temporal resolution at the very beginning and end of the block, but this cannot be an issue with the 1024 sample FFT, simply because this job is up to the short FFT.

So can you please reconsider using the following 1024 sample FFT windows: -448:575, -64:959. With this the center of the FFT window is just 64 samples (1/16 of the window length) away from the edges, and think this isn't a problem for catching problems at the edges (and temporal resolution issues are catched up by the short FFT, not the 1024 sample FFT, and the 64 sample FFTs can be centered at the edges). The advantage is in the middle area of the block as this area is covered better now by the 2 FFT windows. With the center points at the very edges we are already 50% away from the FFT centers when it's about the middle of the block, and the samples there participate only partially in the FFT analyses. If you do a third long FFT centered at the block center the way you wrote about (but I'm not sure whether this is in action right now) things are alright of course, but at the cost of an additional FFT window.

The -448/-64 method does not benefit from the code speedup as the 0:1023 existing FFT is recycled as the -512:511 in the next codec_block ...

... neither does it benefit from a 50% overlap between FFT analyses. ....

Quote from: Nick.C on 2008-01-24 19:50:44

The -448/-64 method does not benefit from the code speedup as the 0:1023 existing FFT is recycled as the -512:511 in the next codec_block ...

I see, this was the speedup trick. Clever done.

Quote from: Nick.C on 2008-01-24 19:50:44

... neither does it benefit from a 50% overlap between FFT analyses. ....

I do not understand why you want a 50% FFT overlap for neighboring blocks. We have a per block analysis and determination of bits to remove. Ideally we don't consider samples at all from neighboring blocks, it is a negative side effect that we have to accept due to the nature of the FFT window. Sure we want accuracy at the block's edges so the FFT windows will reach into the neighboring block. But to do so to a smaller degree than 50% if we can allow is better than reaching 50% into the neighborhood.

But the speedup thing is valuable, especially for -3 with its excellent speed.
What do you think about the -448:575, -64:959 windows for -2, or at least for -1?

... I hear what you say - all three options are now available in lossyWAV beta v0.7.2, attached to post #1 in this thread.

Ideally we don't consider samples at all from neighboring blocks, it is a negative side effect that we have to accept due to the nature of the FFT window.

Quote from: halb27 on 2008-01-24 22:35:02

Ideally we don't consider samples at all from neighboring blocks, it is a negative side effect that we have to accept due to the nature of the FFT window.

Not quite - the concepts of time and frequency are linked, and you can only have the frequency accuracy of a 1024-point FFT by looking at 1024 samples. If you want that accuracy (and I believe we do) you need that many samples. So no, even "ideally" we need to consider samples from neighboring blocks - just as, at the limit, a single sample tells you nothing.

As long as there is at least 50% overlap, and all the blocks is covered by a 0.5 or higher parts of the window function, it really doesn't matter which of the two or three proposed schemes you use.

You're looking for the quietest part, and that could be anywhere in the block. Focusing on the start, middle, end, or any point(s) in between has no advantage in this respect.

What we do know is that something special can happen at block boundaries which cannot happen anywhere else (we introduce a transition), so focussing on these has some merrit, but I wouldn't argue to the death for it!


The worst case scenario is this: you have a notch in the frequency spectrum that's narrow enough that you need a 1024 point FFT to catch it (otherwise the shorter FFT will catch it anyway, and the position of the 1024 point FFT doesn't matter!). Now, switch this notch in and out at block boundaries, so one block has it, and the next doesn't. If the notch is in white noise, we won't hear the switching transients, so we can switch in a single sample. ...

As there were several changes since I tested lossyWAV the last time, I did it again (using -3 -noclips -overlap) and tried to abx my usual problem samples and 2 regular tracks with french female voices.
Everything's fine. The only slight suspicion was with badvilbel where I thought I could hear more noise than in the original. I arrived at 4/4 which turned into a 5/10 finally. So I can't abx it.

Great, Nick! Thank you very much (cause I was thinking already that it wouldn't be bad to have the center of the 1024 sample windows a further bit more inside the block.

Just in order that I don't do something wrong can you please comfirm ot tell me I'm wrong:

a) -overlap 6 means: we have 2 1024 sample FFT windows per block with the center of each being in the block and 96 samples away from the edges?

b) -centre means: we have 3 1024 sample FFT windows per block, 1 with the centre at the block's centre and 2 with the centre at the block's edges?

Using new v0.7.3 -3 -noclips -overlap 8 I tried my usual killer samples as well as some regular music again.
Everything's fine.
Average bitrate for my sample set of full length regular tracks is exactly 400 kbps.

lossyWAV beta v0.7.4, Copyright © 2007,2008 Nick Currie.

Not a big issue, but 0.7.5 beta still says 0.7.4 

Quote

lossyWAV beta v0.7.4, Copyright © 2007,2008 Nick Currie.