Re: SV8 samplerate support

Hi, here is message from Frank, but in German ( dont know if i find time=20
to translate ) :

Frank Klemm wrote :

Bitte vermeide unter allen Umst=E4nden, diese E-Mail-Adresse zu
ver=F6ffentlichen.
SPAM macht mittlerweile die Kommunikation via E-Mail an mehreren Stellen
unm=F6glich und
kostet mich mittlerweile (zu Hause) viel Geld, Zeit und Nerven.
Antworten in Englisch oder Deutsch, wie mir gerade zumute ist.

Antworten (geteilt mit "=3D=3D=3D=3D=3D=3D=3D=3D") bitte teilen, auf gro=DF=
e E-Mails
antwortet nie jemand.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>>
>> As the non-native sample frequencies always get resampled to one of th=
e
>> native sample frequencies, wouldn't it be nicer to support every possi=
ble
>> samplerate?
>>
>> I mean that not 1 sr should be handled as that 1 sr, but a whole range=
 of
>> samplerates should be handled as 1 sr. This way you only need a number=
 of
>> supported/defined input samplerates but you'll still be able to suppor=
t
>> every single samplerate (as long as you have a resampler that supports
> =20
>
every

>> single samplerate). Something like this (taken from AAC):
>>
>> if (92017 <=3D samplerate) return 96000;
>> if (75132 <=3D samplerate) return 88200;
>> if (55426 <=3D samplerate) return 64000;
>> if (46009 <=3D samplerate) return 48000;
>> if (37566 <=3D samplerate) return 44100;
>> if (27713 <=3D samplerate) return 32000;
>> if (23004 <=3D samplerate) return 24000;
>> if (18783 <=3D samplerate) return 22050;
>> if (13856 <=3D samplerate) return 16000;
>> if (11502 <=3D samplerate) return 12000;
>> if ( 9391 <=3D samplerate) return 11025;
>> return 8000;
>>
>> Well, I know this is not really important  but I can't really find
>> anything else to somment on yet.
>>
> =20
>
Interessant, identisch aussehenden Code hatte ich mal zu Lame hinzugef=FC=
gt,
in den 2 Monaten,
in denen ich Schreibzugriff hatte=20

Dateiformate sollten so wenig Restriktionen wie m=F6glich haben. MPEG Lay=
er
1, 2, 3, AC-3,
aber auch AAC haben in dieser Beziehung einige M=E4ngel. Generell ist es =
eine
gute Idee, Formate
erst mal generisch zu designen und dann f=FCr bestimmte Applikationen die=
se
nachtr=E4glich
k=FCnstlich einzuschr=E4nken. Beispiel:

Bei AC-3 h=E4tte man gut getan, Bitrate, Samplefrequenz etc. in weiten
Grenzen freizugeben,
z.B. 16 bit f=FCr die Blockl=E4nge in Byte (bei 48 kHz sind dann Datenrat=
en bis
16 MBps m=F6glich),
18 bit f=FCr die Abtastfrequenz in Hz.

F=FCr jede Applikation gibt es dann zus=E4tzliche Restriktionen:
- Terristisch TV:    =3D=3D 384 kbps, 48 kHz, bis 5.1
- Video CD           <=3D 384 kbps, 48 kHz, bis 5.1
- DVD:               <=3D 512 kbps, 48 kHz, bis 5.1
- Digitalradio:      <=3D 512 kbps, 48 kHz, bis 5.1  oder
                     <=3D 256 kbps, 24 kHz, bis 2.0
- Kino:              <=3D1411 kbps, 48 kHz, bis 7.1
- HD-DVD:            <=3D1411 kbps, 48 kHz, bis 7.1
- DVD-A              <=3D6144 kbps, 48 kHz, bis 7.1
                     <=3D9800 kbps, 96 kHz, bis 7.1
- AV-Receiver        <=3D 512 kbps, 48 kHz, bis 5.1  oder
                     <=3D 256 kbps, 24 kHz, bis 2.0
- AV-Receiver Audio+ <=3D6144 kbps, 48 kHz, bis 7.1
                     <=3D9800 kbps, 96 kHz, bis 7.1
                     <=3D 256 kbps, 24 kHz, bis 2.0

Warum auf einer DVD die Audiodaten als CBR gespeichert werden, obwohl der
Videodatenstrom schon VBR ist,
ist mir auch schleierhaft.

Das Format sollte flexibel sein. Der Encoder sollte aber trotzdem resampe=
ln
k=F6nnen,
denn es ist meistens unklug, etwas mit 51234 Hz Abtastrate zu kodieren.
Weiterhin empfehle ich, auch so was wie 88.2, 96, 176.2, 192 kHz auf 44.1
bzw. 48 kHz
zu resamplen. Meist sind diese exotischen Frequenzen schlechter getunt un=
d
klingen
schlechter (d.h. es sind bei gleicher Bitrate h=E4ufiger Kodierfehler zu
h=F6ren).

Weiterhin widerspricht es dem Konzept jedes verlustbehafteten Codecs,
Abtastfrequenzen oberhalb
48 kHz zu verwenden. Die obere Grenzfrequenz verschiebt sich nur sehr
langsam bei hohen Bitraten
nach oben. Bei =FCblichen Psychomodellen landet man meist bei max. 1 weit=
eren
Kilohertz pro 40 kbps/Kanal.
48 kHz sind dann bis ca. 500...550 kbps/Stereopaar ausreichend. 64 kHz bi=
s
1200...1400 kbps/Stereopaar.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


>> can anybody who can actually read the bitstrem specs check if Frank ha=
d
>> already included his DRC proposals in the specs or not ?
>>
>> Frank had discussed that with us, i guess it was on the matroska-devel
>> list, and i wonder if he had updated the bitstream description after t=
hat
> =20
>
?

>>
>> One question about DRC :
>>
>> I understand that for a lossy codec you can implement DRC very well in
>> the iDCT process during decoding, but how would one make that happen f=
or
>> a lossless mode :O ??? AGC sucks normally  .....
>>
> =20
>
DRC is not included into the specs. There is still the question opened,
should it
be part of Matroska or part of Musepack. As part of Matroska it can be
applied to
all audio tracks independent of the encoding (MPC, PCM, AAC, Vorbis, MP2,
MP3, AC-3).
In Musepack it is only applicable to MPC.

DRC has only very very little to do with AGC. It is a gain control
controlled by metadata
in the bitstream which is proposed by the bit stream creator.
Typically DRC metadata don't have the disadvantages of AGC, it typically
looks forward and
backward, uses psychoacoustic models to evaluate perceived loudness and
last but not
least it is manually edited when the result is not okay.

OFF-TOPIC:
For a high quality volume control you also need DRC data. When listening
very loud and very silent,
perceived dynamic is larger than at medium levels. Equal loudness contour=
s
are not equidistant.
They are closer at low frequencies and also at low and high levels.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


>>
>>- guarantee backwards compatibiliy, means that old SV7 files should be
>> convertable to SV8 ( with special tools ) in a lossless process, but
>> still be fully spec compatible SV8 files
>>
> =20
>
SV8 sollte bis zu 16 Subformate beinhalten. Eines ist eines, welches
verlustfrei
SV7 aufnehmen kann.


>>- make sure the SV8 specs offer a lot more functionailities than SV7, s=
o
>> that MPC SV8 can be used for hi-quality movie encodings as well as for
>> DVDs, where space is maybe not a big issue anymore.
>>
> =20
>
Bitrate von bis zu 300 kbps pro Kanal ist bei entsprechenden Einstellunge=
n
selbst bei SV7 kein Problem. Dar=FCber w=FCrde ich zu lossless gehen
(bei Klassik typisch 300 kbps/Kanal, HeavyCompressed Pop bis 500
kbps/Kanal).


>>- consider to check if its possible to allow peeling for MPC SV8, so
>> that users can store their MPC files with rather high bitrates on DVD =
or
>> CD media, but can peel the files down in bitrate so they could be
>> transferred onto portable players ( of course, this is NOT a lossless
>> process anymore )
>>
> =20
>
Ich bezweifle, da=DF Peeling =FCberhaupt funktioniert. Wenn es was
funktionierendes
geben sollte, ist das schon mystische Mathematik.
Problem 1:
  - man ben=F6tigt riesige Codeb=FCcher, wenn die Peelingverluste nicht
deutlich gr=F6=DFer
    werden sollen als die einer Rekodierung. Riesig hei=DFt, da=DF die
Lookup-Tabellen,
    die ich zum Dekodieren benutze, nicht mehr maximal 1 KB gro=DF sind,
sondern
    im oberen GByte bis mittleren TByte-Bereich liegen.
  - aber selbst das ist immer noch suboptimal
  - =FCber Geschwindigkeit habe ich mir dabei noch keine gedanken gemacht
Problem 2:
  - beim Wechsel von 160 kbps =3D> 64 kbps, dem interessanten Bereich, ko=
mmt
noch hinzu,
    da=DF kein Wechsel zu "enhanced Coding tools" m=F6glich ist, z.B. IS,=
 PNS,
schlechtere
    Richtungskodierung.



>>- add a loss less mode to SV8, and the speciality here is that mixing
>> lossy and lossless modes in one and the same file should be possible,
>> just like in the upcoming Wavpack4 from David Bryant ( who i am copyin=
g
>> on this email, i dont wnat to 'steal' his idea without at least tellin=
g
>> him   )
>>
> =20
>
Vom technischen Standpunkt das Mixen von Lossy und Lossless nicht sehr
sinnvoll.
F=FCr L und R achte ich darauf, da=DF ja kein Bit vom Original verschiede=
n ist,
bei C, RL und RR lasse ich im schlimmsten Fall 60 bis 70 dB st=E4rkere
St=F6rger=E4usche
zu. Nachdenken kann man, ob man f=FCr L und R eine andere
Qualit=E4tseinstellung als
f=FCr C, RL und RR zul=E4=DFt. Aber schon das ist technisch gesehen fragw=
=FCrdig.
Wenn St=F6rger=E4usche h=F6rbar werden, ist es egal, ob L und R lossless =
kodiert
wurden.
Es ist weiterhin falsch, C, RR und RL bei einer 5.1-Aufnahme als
nebens=E4chlich
anzusehen. Die sind dort genauso wichtig wie L und R. Wenn auf C, RL und =
RR
wenig
Signal ist, ist deren Bitrate geringer als die vom L und R. Das ist dann
aber okay.

Wenn lossy und lossless gemischt werden soll, dann sollte so was in
Matroska gemacht werden.
Ein Kanal als AAC, einer als MP3, einer als MAC, einer als Ogg, ...=20

>> To make one thing clear out front, i dont know if Frank has thought
>> about all these things in his current specs, because i am sorry i am n=
ot
>> capable reading technical specs at all, but from a user perspective i =
am
>> convinced these features could lift MPC on a new level, and make a big
>> differentation from other formats.
> =20
>

Features sind immer willkommen, ob sie sinnvoll sind, dar=FCber mu=DF
allerdings
diskutiert werden. Es macht wenig Sinn, reine Marketing-Features
aufzunehmen und
alles dadurch wesentlich komplizierter zu machen, daf=FCr wirklich wichti=
ge
Features
zu vergessen (auch wenn alle anderen sie vergessen haben).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


>> Current spec only allows bandwidth scalability (normal for subband
> =20
>
coders),

>> but not scalable quality (AFAIK).
>>
> =20
>
>>>> - add a loss less mode to SV8, and the speciality here is that mixin=
g
>>   =20
>>
lossy and lossless modes

>>>> in one and the same file should be possible, just like in the upcomi=
ng
>>   =20
>>
Wavpack4 from David

>>>> Bryant ( who i am copying on this email, i dont wnat to 'steal' his =
idea
>>   =20
>>
without at least telling

>>>> him   )
>>   =20
>>
>>
>> I'm not sure if you can make a subband coder lossless. Subband
> =20
>
filterbanks

>> can be lossless, but you always end up with values to round in the cod=
er.
> =20
>
It

>> could be possible if you use some integer lifting scheme in the
> =20
>
filterbank,

>> but I'm not sure. Of course using a completely different coding method
> =20
>
for

>> the lossless part, or error part, is also possible.
>>
> =20
>
Lossy codecs and lossless codecs are working completely different.
Compared with this subband and transform lossy codecs are the same.
One or more than one lossless codec can be added to Musepack.
I propose to take one or more than one of the existing:

  - FLAC
  - LA (ask author, may be he partially opens the source for the project)
  - LPAC (source code not open)
  - Monkey's Audio
  - OptimFrog (ask author, may be he partially opens the source for the
project)
  - WavePack

Define the features and the interface you need for the file format:
  - Seeking
  - Partially decoding
  - Partially encoding/replacing
  - library interface
and every file format which supports this interface can be used with
matroska.
Interface should be able to replace a small part inside without
decompressing and compressing the whole audio file.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


>>>> Third, I'd propose to separate entropy coding from the rest
>>>> (just as the psymodel would be modularized too). This way I
>>>> could implement a nice arithmetic coding layer for those who
>>>> want to save maximum space=20
>>   =20
>>
>>
>> Arithmetic coding is adaptive, this will not save space, but increase
> =20
>
needed

>> space. Because in an audio coder you only code small data sets (you wa=
nt
> =20
>
the

>> file to be randomly accessible) adaptive compression will not work.
>> A well tuned set of Huffman tables will probably compress much better =
and
>> allow much faster encoding and decoding.
>>
> =20
>
Arithmetic encoding can use static as well as dynamic propability models
like Huffman or
Range coding. Main disadvantage is that arithmetic coding is much slower
than huffman coding
and the need of much more space.
And the advantage of arithmetic coding is very little. The huffman code
tabel generator calculated
this "huffman loss". Typical for 18 kHz bandwith, 2 channels is around 0,=
2
kbps.
Not worth the effort.

A typical tool to enhance huffman coding is grouping of samples. Often th=
is
result in better
compression than arithmetic coding, because this also uses intersymbol
correlation.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


>> Also it would be good if for a given channel, lossy <-> lossless
>> switching could be done on a reasonable boundary (~1 second? ~1 frame?=
).
>> Even more space can then be spared on unimportant parts of a track.
>>
> =20
>
Switching of coding models is a very dangerous thing. It is possible that
it becomes
audible even then switching from one transparent coding to another.
Coding errors are much easier to detect when they are not constant.
And alos note the big gap in bitrate between (nearly transparent) lossy
encoding (140...160 kbps)
and lossless coding (600 bis 1000 kbps for CD).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


>> Huffman coding is a subset of Arithmetic coding, where all probabiliti=
es
>> must be inverse powers of 2. It's faster, but it IS less efficient.
> =20
>

Loss of huffman coding is only significant for small tables. Even when th=
e
huffman codes look awful, the huffman loss is moderate.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


>> Thats only one possible way of using it, for different channels ina
>> multichannel file, but i was thinking about using lossless also for ve=
ry
>> complex passages, like a fortissimo in orchestral music or explosions
>> etc. in movie soundtracks.
> =20
>

Das ist auch so ein rumgeisternder Unsinn. Komplexe Passagen, die in
Musepack
zu 400...500 kbps f=FChren, landen im Lossless Mode meist auch bei 1000 b=
is
1200
kbps. Weiterhin ist ein Umschalten zwischen Lossy und Lossless auch alles
andere
als effizient. Lossy Codecs arbeiten mit =FCberlappenden Bl=F6cken. Die
=DCberlappungsbereiche
m=FCssen sowohl lossy wie lossless kodiert werden. Und das Propability-Mo=
dell
des
Lossless-Coders ist noch nicht aufgebaut. Er arbeitet am Anfang auch sehr
sehr ineffizient.

Weiterhin fressen Explosionen wenig Datenrate. Tiefe Frequenzen maskieren
sehr gut.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Hybrid-Codecs:

ich habe mal dar=FCber nachgedacht, wann man sie wirklich braucht. Ich ha=
be
*keine*
*einzige* sinnvolle Anwendung gefunden. das klingt so hart, da=DF ich es =
noch
nicht gesagt habe.

In allen F=E4llen erkauft man sich f=FCr 5 Cent/Audio-CD erhebliche
Mehraufw=E4nde beim Handling und
eine doppelt so gro=DFe Gefahr des Verlustes der verlustlosen Kodings.
Weiterhin sind bei
maximal vergleichbarer Qualit=E4t die lossy Codings doppelt so gro=DF wie=
 bei
g=E4ngigen
verlustbehafteten Codecs. ich habe etwa 500 lossless kodierte CDs und ich
m=FC=DFte wirklich
ziemlich irre sein, wenn ich zur Rekonstruktion dann immer nach der
doppelten Anzahl von
CDs suchen m=FC=DFte. Manche CDs sind so schon auf zwei CDs (Titel 1..6 a=
uf
CD452,
Titel 7...16 auf CD453). Wenn man f=FCr den zweiten Teil dann noch mal su=
chen
m=FC=DFte.
Nein, das will ich mir nicht ausmalen.

Wesentlich interessanter ist es, statt "Raid-0" mit Audio-Daten ein
Pseudo-"Raid 1"
zu spielen. Fehler in Lossless files mit Hilfe von Lossy-Files zu
kaschieren.

OptimFrog --repair --lossy Axel_F.mpc --source Axel_F.ofr --destination
Axel_F.wav

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


>>>> Current spec only allows bandwidth scalability (normal for subband
>>   =20
>>
coders),

>>>> but not scalable quality (AFAIK).
>>>>
>>   =20
>>
>> Hmmm ..... i hope Frank could consider to add this to the bitstream
>> specs, its an important thing to have it in the specs at least, even i=
f
>> its done in a later stage ....
>>
> =20
>
Wof=FCr ben=F6tigt man das wirklich? Bitte keine "me too"-Features, von d=
enen
keiner wei=DF,
ob sie je funktionieren werden oder ob sie =FCberhaupt funktionieren k=F6=
nnen.

Bis jetzt:
- G=E4ngige Methoden ergeben mittelm=E4=DFige Qualit=E4t und sehr hohen A=
ufwand
oder schlechte Qualit=E4t und hohen Aufwand
- die Ogg Vorbis-Beispiele waren schlechter als ich bef=FCrchtet hatte
- Die MPEG-4 BSAC waren immer noch deutlich schlechter als die direkt
kodierten Bitstr=F6me, und da haben sich garantiert einige
  geniale K=F6pfe Gedanken gemacht
- Selbst in MPEG-4 wurde angegeben, das BSAC zum =DCberbr=FCcken von
Datenrateneinbr=FCchen zu verwenden ist, nicht
  zum Bereitstellen von verschiedenen Datenraten

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


>> compression methods dont have a DCT/iDCT stage, so that DRC could be
>> done on the Coeefficients, and no AGC-like 'pumping' could occur. AC3
>> does a pretty good job for that, and for movie soundtracks its a
>> necessity IMHO, as you can never say what speakers/amps will be used t=
o
>>
> =20
>
DRC can also be applied to other representation of audio. For application
to normal PCM you need to smooth the sample points of the DRC envelope
a little bit. Can be done by splines or by overlap-and-add of suitable
waveforms. Last method is equivalent to DCT/iDCT method of AC-3.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Proposal for matroska:
- You can encode 0, 1, or more streams
- every stream contains something between 1.0 and 255.15 channels
- you can create new streams by multiply-and-add of other streams (virtua=
l
streams):

Example for streams:
- Stream  1: English   Soundtrack 5.1
       400 kbps
- Stream  2: German    Soundtrack 5.1
       400 kbps
- Stream  3: French    Soundtrack 5.1
       400 kbps
- Stream  4: Spain     Soundtrack 5.1
       400 kbps
- Stream  5: Portugese Soundtrack 2.0
       400 kbps
- Stream  6: Producer Comments English 1.0
        70 kbps
- Stream  7: Producer Comments German  1.0
        70 kbps
- Stream  8: Lossless Correction 5.1 of English Soundtrack
      2000 kbps
- Stream  9: Lossless Correction 5.1 of German  Soundtrack
      2000 kbps
- Stream 10: Audio Description Support English 1.0 (visual impairment)
        70 kbps
- Stream 11: Audio Description Support German  1.0 (visual impairment)
        70 kbps
- Stream 12: Director Comments English 1.0
        70 kbps
- Stream 21: DRC for Soundtrack
       < 1 kbps
- Stream 22: DRC for Soundtrack for Comment Track English
       < 1 kbps
- Stream 23: DRC for Soundtrack for Comment Track German
       < 1 kbps
- Stream 24: DRC for Comment Track English
       < 1 kbps
- Stream 25: DRC for Comment Track German
       < 1 kbps
- Stream 26: DRC for Soundtrack for Hearing Impairment Support
       < 1 kbps
- Stream 27: DRC for Soundtrack for Hearing Impairment Support
       < 1 kbps
- Stream 28: DRC for Soundtrack for Comment Track Director English
       < 1 kbps
- Stream 29: DRC for Comment Track Director English
       < 1 kbps

Virtual streams:
- Stream  1 * DRC(Stream 21)
- Stream  2 * DRC(Stream 21)
- Stream  3 * DRC(Stream 21)
- Stream  4 * DRC(Stream 21)
- Stream  5 * DRC(Stream 21)
- ( Stream  1 * DRC(Stream 22) + Stream  6 ) * DRC(Stream 24)
- ( Stream  2 * DRC(Stream 23) + Stream  7 ) * DRC(Stream 25)
- other combinations of that
- Stream  1 * DRC(Stream 26) + Stream 10
- Stream  2 * DRC(Stream 27) + Stream 11
- ( Stream  1 + Stream  8 )* DRC(Stream 21)
- ( Stream  2 + Stream  9 )* DRC(Stream 21)
- ( Stream  1 * DRC(Stream 28) + Stream 12 ) * DRC(Stream 29)

Especially for the Comment tracks you have still a 5.1 background sound,
but you only
need 70 kbps for the mono comment track. And you still have a chance to
make the background noise
louder or not so loud.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

So far for today. Oh Gott, it is after midnight.

--
Frank Klemm

PS: Erschreckend ist, da=DF es bei all diesen Fragen im wesentlich um all=
es
m=F6gliche ging, nur nicht
um die Hauptaufgabe einer Kodierung. Alles im wesentlichen Features, bei
denen ich mir sicher bin, sie nie
zu brauchen, die aber nach vielk=F6pfigen Programmierteams schreien, die =
sich
10 Stunden pro Tag um das
Thema k=FCmmern k=F6nnen.

Das erinnert mich an DVD-A und SA-CD. 192 kHz Abtastfrequenz, die
nachweislich niemand h=F6rt, aber ein
grottenschlechtes Lautsprechermanagement, so da=DF man lieber AC-3 384 kb=
ps
sich anh=F6rt als die
6 Mbps DVD-A-Tracks. Warum kann ich den Sub nicht auf die Frontstandboxen
umleiten, die ab 28 Hz ordentlichen Pegel machen?
Warum kann ich die Hauptlautsprecher nicht gegen=FCber dem Sub verz=F6ger=
n, so
da=DF ich die Gruppenlaufzeitunterschiede
nicht ausgleichen kann. Warum kann ich das Bild eines DVD-Spielers nicht
verz=F6gern, damit auch bei
DSP-entzerrten Boxen Bild und Ton wieder =FCbereinstimmen?

Ich glaube, da=DF man in dieser Richtung gew=E4chsh=E4userweise Blument=F6=
pfe
gewinnen k=F6nnte, denn selbst s=FCndhaft teuere
DVD-Spieler und AV-Receiver bieten hier nur sehr sehr l=F6chriges.

--
Frank Klemm



http://mpc.corecodec.org