Not sure why the internals of the codecs are so interesting to you. But the Fraunhofer xHE-AAC decoder documents possible frame lengths to be 768, 1024, 2048 or 4096. Technically the sources speak about USAC, but not sure there's a difference between the two here.

I may be stupid, but I don't understand what you refer to by blocks. Some site seems to call frames "blocks" and that's it.
I may further reveal my stupidity, but I think if you have the ability to improve something as complex as xHE-AAC, you would be able to get this information easily without asking from for example public source code.

I don't have the format specs and the code is way too complex to go fully through. I see FDK sources use "block" in variable name and refer to "frame" in same variable's description (INT blockNumber; /*!< frame counter */). Specifically searching for "block" I see references to short blocks and long blocks. Other than that I have no idea what this block is. Good thing I don't need to improve this format, I'd be in trouble.

See Reply#12. And, I currently don't really have the ability to improve something that complex, I just hope I'll have the ability to do that in the future.

Quote from: Klymins on 2024-11-08 16:19:16

See Reply#12. And, I currently don't really have the ability to improve something that complex, I just hope I'll have the ability to do that in the future.

It is really difficult to develop a new codec or at least take an existing codec to a more advanced level. Unfortunately, considering what you have written on this and other topics, this task seems truly impossible for you.

Thanks for solving my confusement. But I want to ask that why you added just one intermediate value @C.R.Helmrich ? Even if only 2 bits are used for giving the block length, this adds enough space for 2 intermediate values. Also, what does "with low window overlap" means? And, what is MPEG-H and how can I get it?

Also, I wonder why these block lengths are selected (and no intermediate values are added) and especially why 1024 and 960 samples are selected as frame lengths (they have a very small difference between them, so why not for example 1024 and 768?).

Quote from: Klymins link=msg=1052056

Thanks for solving my confusement. But I want to ask that why you added just one intermediate value @C.R.Helmrich ? Even if only 2 bits are used for giving the block length, this adds enough space for 2 intermediate values. Also, what does "with low window overlap" means? And, what is MPEG-H and how can I get it?

Also, I wonder why these block lengths are selected (and no intermediate values are added) and especially why 1024 and 960 samples are selected as frame lengths (they have a very small difference between them, so why not for example 1024 and 768?).

Once you've learned about transform windows like sine window and KBD window, about the Princen-Bradley condition for perfect reconstruction during the overlap-and-add process when using the MDCT, about computational complexity and memory requirements and why they matter especially in audio decoders (all of which you can Google/Bing and find books or scientific papers on), you'll be able to answer all these questions yourself. It takes time to learn and understand all these things, and I'm afraid there's no shortcut. You need to know the basics of this "craft" first.

960 samples give you a frame length of exactly 20ms with 48 kHz sampling rate, which is (or was) desirable in some applications... not so much anymore, that's why it was removed when developing xHE-AAC and MPEG-H 3D Audio. A block size of a power of 2, like 1024, or something power-of-2 times a small number, like 768, is easier to implement than other block sizes.

Also, once you've implemented your own first codec, you might find (as others did, as early as the 1980s, during the development of MP3 e.g.) that having lots of flexibility in the choice of block lengths doesn't necessarily make the codec better, because it 1) makes it "harder" to find the "best" block length(s) for an audio frame during ecoding, 2) makes the transitions between blocks of different length more complicated... due to the transform windows, and here we're back at the beginning of this post.

Chris