Christian HJ Wiesner wrote:

>First goal of "transpacked SV7" SV8 is to make the blocks independent from 
>others.
>SV7 uses differential encoding acrossing block boundaries.
>This (the removal of this cross block differential coding) need some 
>additional bitrate, 
>but it makes software design much more simple and makes it easier to write 
>addtional tools.
>
Forgive me if i am talking complete rubbish, but i have more and more 
problems understanding what you are trying to do here :

 From my understanding the SV8 framing should not only bring a new 
framing, but also introduce serious changes to the blocks itself ? If 
you make an app that simply 're-packs' SV7 files into a SV8 framing, 
will the old blocks be converted also, so they are SV8 compliant, or do 
you plan to introduce a 'SV7 compatibility mode' in SV8, so that SV7 
blocks can be put into the new framing ?

For the changes to the blocks itself, i do understand that the follwoing 
new features require a new block design :

- multichannel ( 5.1 )
- more flexible sampling rate support
- DRC
etc.

Now with respect to what you told me on the phone, i mean your ideas 
about leaving the subband encoder design completely for next musepack, 
how about considering tow steps for this :

1. SV8 : subband encoder like SV7, but adding all the new features 
listed above

2. SV9 / new codec name : new encoder based on tranformation encoding, 
or a new OSS AAC encoder

Christian

>First we should discuss about the size of these independent blocks.
>AC3 calls this blocks audioblocks.
>
>* Basic block size of SV7 is 1152 samples. I would use a multiple of this
>  for "transpacked SV7" SV8. Examples:
>
>        a) 2 blocks  => 2304 samples ( 52 ms for 44.1 kHz,  48 ms for 48 
>kHz)
>        b) 4 blocks  => 4608 samples (104 ms for 44.1 kHz,  96 ms for 48 
>kHz)
>        c) 8 blocks  => 9216 samples (209 ms for 44.1 kHz, 192 ms for 48 
>kHz)
>
>        Samples should be stored in a way so it is possible to decode 
>block by 
>        block to minimize memory consumption, even when this is not done 
>in the 
>        reference implementation.
>
>* Native SV8 for 32 kHz...64 kHz sample frequency.
>        a) 4096 samples ( 93 ms for 44.1 kHz,  85 for 48 kHz)
>        b) 8192 samples (186 ms for 44.1 kHz, 171 for 48 kHz)
>
>For 8...16 kHz this is quartered, for 16...32 kHz it is halved, for 
>64...128 kHz doubled
>and for 128...256 kHz four times larger. But this only as remark.
>Frank Klemm
>  
>