Re: Zvuky (???)

[Martin Fedor <martinf@macron.cz>]

Dobry den.
Chtel bych odpovedet na tento dotaz, ackoliv se nepovazuji za odbornika
v oboru zpracovani signalu (resp. zvuku).
Bohuzel se v nekolika reakcich P.Narozneho nakupily takove hlouposti, z
kterych mi vstavaly vlasy hruzou na hlave
a rychle jsem si vzpomnel na nekolik profesoru z dob sveho studia a
zejmena na to, jak by vypadaly jejich pripadne reakce.


Pavel Narozny wrote:
> 
> ...
> >> Mel bych dotaz na hudebni formaty AIFF a WAV.Jakej je v tom rozdil? A co
> >> se tyka mp3 a jeho konverze do AIFF,nebo WAV.Po konverzi se mi ve
> >> skladbach (nejakych) ozyva nahodne zblunkani a splouchani.Jde to
> >> odstranit?A taky by me zajimalo,proc jsou vysledne AIFF,WAV v hlubsim tonu
> >> nez mp3.At jsem nastavil co jsem nastavil,vzdycky to bylo hlubsi. Dik za

Toto byl puvodni dotaz, na ktery bylo odpovezeno, ze rozdil mezi AIFF a
WAV je "maximalne pouze v hlavicce souboru".
Neni tomu tak. Je sice pravda, ze oba typy maji mnoho spolecneho (jsou
to soubory, ktere maji strukturu tvorenou
tzv. chunky, nebol-li logicky oddelenymi datovymi bloky s rozdilnym
vyznamem -- IFF [interchange file format] a WAV je
jen zvukovy RIFF). Pokud oba soubory obsahuji pouze zvukova data v PCM
formatu (pulse coded modulation), tak skutecne se
oba soubory muhou lisit jen v dodatecnych informacich a hlavickach
(hlavicka uvozuje kazdy chunk).
Realita je vsak takova, ze oba formaty umoznuji nest ve svych chunk
castech data ruznych typu a zejmena ruznych kompresi(vcetne napr.
MPEG1-Layer3=mp3), coz vse zavisi jen na tom, zda pro dana data existuje
"codec" -- nebo-li ovladac/program/algoritmus pro jejich dekompresi.
Jeste truchlivejsi realitou je to, ze AIFF se ponejvice vyuziva na Apple
Macintosh, zatimco WAV ve Win32. Proto se lehce narazi na AIFF, ktery ve
Win32 (nebo jinde) nelze prehrat, nebot neexistuje na teto platforme
potrebny "codec" (resp. prevedeny algoritmus pro jejich rozkodovani).

> Zadny. Jen hlavicka je jina. ...ok, wav bude asi v intel bytes (little
> endian) formatu. Co to je? Intel udrzuje cislo tisic takto: 0001
> To je tzv. little endian format. Nejvice vyznamny bit je posledni.
> Motorola pouziva logictejsi big endian format, tisic je proste tisic.
> To je jediny mozny rozdil, co me napada. V MakeCD si muzes zvolit, jestli
> se bude ripovat do little ci big endian formatu...

Tady bych uz chtel spise reagovat na nektere nesmyslne vyroky:
- Intel urcite neudrzuje cislo 1000 ve formatu 0001. Pojem "intel bytes"
je nesmysl, nebot razeni samotnych bitu v bajtu je samozrejme vsude
stejne. Pokud uz bych chtel nejak vysvetlit rozdil mezi little a big
endian, tak bych musel ono cislo tisic nejdriv prevest do takoveho
formatu, aby bylo zrejme razeni bajtu! (1000=03E8h)
- Motorola nepouziva _logictejsi_ razeni bajtu. Jednoduse pouziva _jine_
razeni bajtu. O logice se nema smysl bavit, nebot oba zpusoby ukladani
vicebajtovych slov v pameti maji sve vyhody i nevyhody.

> Diskretni kosinava transformace je vznezeny slovo pro prumerovani a hledani
> podobnych useku... Viz jpeg, v kterym jsou napisy mensim fontem, specielne
> ty kontrastni... Zde i necvicene oko vidi ty artefakty, protoze v zavislosti
> na stupni komprese se urcuje podobnost - nemusi (a nikdy to neni) 100% podobnost,
> takze nam tam zustavaji bugy...
> V mpeg audiu je princip velmi podobny, az na to, za samplovany data jsou
> trosku jine konzistence a sum, takto vneseny do signalu se vyrovna sumu,
> bezne vzniklemu vedenim audio nestineneho kabelu podel sitoveho pripojeni
> ci audio vystupu pres 3.5' stereo jack konektor... :(

Tak z toho jde des a hruza. Nazyvat kosinovou transformaci prumerovanim
a hledanim podobnych useku je do nebe volaji hovadina. Prevod z casove
oblasti do frekvencniho spektra (tzn. jen jiny popis tehoz!) nazyvat
prumerovanim je (a nenabizi se mi jine slovo) DILETANSTVI! Hledanim
podobnych useku se snad jeste da nazvat korelace (prip. autokorelace),
ale integralni transformace???
Absolutne netusim, co pisatel chtel vysvetlit onim "Viz jpeg, v kterym
jsou napisy mensim fontem, specielne ty kontrastni...". Pripomina mi to
jen blaboleni.
Veta "v zavislosti na stupni komprese se urcuje podobnost" je uplnym
nepochopenim JPEG komprese a kdyz uz pisatel pouziva slova jako
"podobnost" snad by se vice hodily na kompresi fraktalni.
Je zrejme zbytecne, abych vse uvadel do poradku. K tomu si staci precist
jakoukoliv knizku o zpracovani signalu, kompresi obrazu nebo primo popis
JPEG komprese! Jenom ve zkratce. DCT se pouzije pro prevod obrazu do
frekvencni oblasti, v zavislosti na stupni komprese se (zjednodusene
receno!) odstrani ze signalu vyssi frekvence (oko v obraze nejvice vnima
nizzsi frekvence) a nakonec vsechny koeficienty jednotlivych zachovanych
harmonickych zakoduje Huffmanovym kodovanim ke zmenseni redundance.
Vrchol vseho je vyrok "...sum, takto vneseny do signalu se vyrovna
sumu...". Komprese timto zpusobem samozrejme zadny sum do signalu
nezanasi (zadne zvyseni entropie). Nevim, kde pisatel dosel k tomuto
zaveru.


Asi by normalne nestalo za to, tento e-mail komentovat, ale mnozstvi
blabolu, ktere se v nem objevily, a zejmena protoze se tvari jako
"edukativni", mne donutilo na tyto nesmysly upozornit.

Na zaver si neodpustim poznamku, ze pokud pisatel podobnym diletantskym
zpusobem mluvi do vseho, pak Buh s kazdym, kdo mu nasloucha...


defor