Původní podoba příspěvku
Surová data tak, jak byla v roce 2013 stažena z Pandory (HTML zdroj bez úprav, osobní e-mailové adresy jsou maskované).
<!--------------------------------------------------------------> <table width="100%"><tr><td align="left" valign="middle"></td><td align=right valign="middle"></td></tr></table><BR><pre>Zvukovky se delaji s vzorkovacim kmitoctem jak 44.1kHz tak 48kHz, zalezi na <img src="BODY_IMAGES_WRAP_GIF"> chipsetu. Uvnitr casto byva "sample rate converter", ktery to cele "podela". <img src="BODY_IMAGES_WRAP_GIF">Bohuzel nevim, jak korektne detekovat na konkretni zvukovce, aby se SRC nepouzil <img src="BODY_IMAGES_WRAP_GIF">a data sla primo na vystup. Asi by byly lepsi dve rutiny, jedna pro 44.1 a druha pro 48kHz. A kazdy si <img src="BODY_IMAGES_WRAP_GIF">vybere rucne tu, ktera mu vyhovuje... S tim bit 5,(HL) je to dobry napad :-) Nahodou na to jednoduche FSK ses nedival ? V. <span class="replyquote1">> > D. za info, trochu som sa pohrabal v zdrojákoch a viac hádam ako viem, ale > uvazujem takto: > > 1) velku inspiraciu som nasiel na tejto stranke: > http://code.google.com/p/otla/wiki/ComoFunciona > az po tvojej reakcii som pochopil, ze sa jedna o popis len jednej z metod, > podla popisu v zdrojakoch (textos.cpp) to tipujem na metodu ultra alebo > fiq... > podla zdrojakov (rutinas.cpp) sa v loaderi metody raudio pracuje s > registrom R - co prinasa o cosi vyssiu presnost pri merani casu (klasicky > inkrement zabera cca Nx24+5 + X taktov, kdezto cez R to je Nx20+5 +X - > mozno to robi nejaky rozdiel...) > skusim pospekulovat o vyuziti R registra... ma niekto skusenosti? > > aj ked: v ich vzore pouzivaju IN F,(C) co je uzasna vec, netreba maskovat > bity, ale ja som ich ofintil - vdaka BIT 5,(HL) s HL na E002 vieme nacitat > stav CMT na 8 taktov, im to trva 12 :-) takze s ich R registrom su zhruba > tam kde my bez R... > > 2) siel by som cestou spolahlivosti - extremne rychlosti nepodporuju > chcecksum a tak sa po sice kratkom nahravani pocitac s istou > pravdepodobnostou aj tak sekne... > > 3) z popisu ich algoritmov usudzujem, ze asi nik nesiel cestou "mojho" > kodovania troch bitov - pritom, ak by sa vyuzil este jeden volny bit > (3+3+2+1) a ten sa pouzil na podmienenu negaciu bajtu, dal by sa > statisticky ziskat este asi dvojnasobok rychlosti (lebo by sme vynegovali > bajty, ktore maju moc jednotiek a viedli by k dlhym vlnam). > > > > este jednu otazku doplnim k tym predtym - ma niekto v plane kodovat > nahravky do MP3 a pripadne ich pustat cez MP3 player? podla skusenosti s > k7zx (takze ani t7zx ani m7zx :-) vraj MP3 playere funguju na 48kHz, kdezto > bezne zvukovky a CD playere na 44,100 - resamplovanie robi zasadny rozdiel > v kvalite nahravky, moze to uplne rozhadzat synchronizaciu). tak by ma > zaujimalo, ci mam ratat so samplovanim na 48 aj 44,1... > > > Feri </pre>