lossyWAV Development
Reply #832 – 2008-01-24 19:50:44
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. I would rather go down the -256:767 route if we are going to deviate from the -512:511;0:1023 route. Someone with more knowledge than me should ultimately make the decision, but if the existing -512:511;0:1023 is not acceptable then my preference is clear.