Ez talán a legilletékesebb (PPéter) tollából született, ugyanezen fórumon:
"/.../A gyorsabban írt (égetett) Audio-CD lemezek minőségi romlása nem csak szubjektív hallási tapasztalat kérdése. Természetesen műszerrel is mérhető a különbség. Erre többfajta eszköz létezik, a mastering üzemek általában speciális, meglehetősen drága célhardvereket alkalmaznak erre a célra.
Tehát adott a nagy kérdés: miért lehet különbség CD és CD között, ha zenei korongról beszélünk? Miért lehet rosszabb a minősége egy CD-R lemeznek, mint egy gyári lemeznek, amelyről másolatot készítettünk?
Hogyan lehetséges mindez, amikor ugye - elvileg - a CD digitális adathordozó?
Úgy lehetséges, hogy bár az interpretált adat, (amelyet a fizikai dekódolás után digitálisan értelmez a lejátszó eszközünk) valóban digitálisnak mondható (annak minden előnyével és hátrányával együtt ), a fizikai jelek a CD lemezen meglehetősen bonyolult rendszerben, optikai úton tárolódnak és olvasódnak le.
Na és? - kérdezhetnénk. Csakhogy van egy kis probléma. Mégpedig a leolvasás, a dekódolás elve, működési rendszere, amely - valljuk be - igencsak gyenge, ha mai szemmel nézzük.
Az optikai tárolás miatt CD lemezeken az adatok nem a megszokott formában tárolódnak, tehát nem 8 bit (azaz 8 optikai jel) ábrázol egy bájtot, hanem 14. Erre azért van szükség, mert a 8 bites ábrázolás esetén előfordulhatna olyan kombináció is egy-egy bájt ábrázolásakor, amely egyáltalán nem tartalmazna 1-esre állított bitet (ilyen pl. a nulla érték ), vagy csupa 1-esből állnak (mint a 255, ). Komolyra fordítva a szót, ha 8 biten ábrázolnánk az adatokat, akkor nem lehetne optikailag bztonságosan megkülönböztetni az egy-egy bájthoz tartozó jeleket (vagy szüneteket), elveszne a szinkronizáció. Ezért 14 biten dolgozik a CD, mégpedig úgy, hogy kiválasztották a 14 bittel alkotható sok-sok kombinációból azt a 256-ot, amely a lehető legváltozatosabban tartalmaz 1-es és 0-ás biteket, elkerülvén azt, hogy egymás után több, azonos állású bit megzavarja a leolvasást. Ez az eljárás az EFM (Eight-To-Fourteen) kódolás, amely egyszerűen, egy táblázat alapján zajlik, 0-tól 256-ig minden értéknek megvan a maga 14 bites EFM párja. A szinkronizáció könnyítése érdekében a 14 bites bájtok közé egy-egy három bitből álló elválasztó mező is kerül, tehát már ott tartunk, hogy 14+3 biten ábrázolunk fizikailag egy-egy bájtnyi adatot, ami normál esetben (a mi megszokott számítógépes világunkban) ugyebár 8 bit lenne.
Mi reprezentálja fizikailag a biteket a lemez felüketén? A pitek. Ezek apró gödrök (a gyári, préselt lemezen), amelyek az 1-es számot képviselik, illetve a sima területek a land-ek, ezek a 0-át reprezentálják. AZ írható CD-n ez kicsit másképp néz ki, mert a lézer nem olyan szép, hosszúkás árkocskákat éget a hordozótétegbe, mint amilyeneket a préselt gyári CD-ken láthatunk, hanem buggyos szélű hólyagokat. Az optikai leolvasás számára nagyjából ugyanazt a hatást keltik mint a gyári szabványos pitek, ezért olvashatóak le közel azonos módszerrel. Már egyébként itt is látszik, hogy a gyári CD nem azonos a CD-R lemezzel. Persze ez még nem jelent semmit - bár a CD-R lemezek dekódolása során komoly számokkal fejezhető csak ki a legtöbb asztali lejátszó tévesztési aránya a gyári lemezek lejátszásához képest!
A leolvasás során az olvasófej sorra dekódolja a spirálisan kifelé tekeredő track mentén a piteket és a landeket. Már itt is bejön egy érdekes momentum, mégpedig az, hogy a gyári CD lemezek spirális nyomvonala meglehetősen szabályos, míg az írt CD esetén többször találkozhatunk ennek a spirális "nyomvonalnak" a szabványtalanságával, torzulásával, ami a dekódoláskor sokat ronthat az pitek és lendek tiszta felismerésén és elkülöníthetőségén. De ne szaladjunk ennyire előre. Már a jelek helyes értelmezése is nehéz feladat, hiszen messze nem steril körülmények között dolgozik a lejátszó, ezért a legapróbb karcolás, porszem is jelek tucatjait teszi felismerhetetlenné. Ne feledjük, mikronokból beszélünk!
Az EFM formátumú adatokat 33 bájtos etapokban kapja a dekóder, ezeket a 33 bájtos adagokat hívjuk frame-nek is (itt már normál 8 bites bájtokról beszélünk, az EFM dekódolás alacsony szinten hardveresen történik). A 33 bájtból 1 bájt az úgynevezett szubkód alcsatorna, 32 bájt pedig az adat. A 32 bájtból azonban csak 24 bájt a hasznos anyag, 8 bájt szolgál a hibadetektálásra és a hibajavításra. Mire elegendő ez a 8 bájt? Nem túl sokra. Egy kétmenetes hibaellenőrző algoritmus található az Audio CD lemezeken. Az első körben a 8 bájtos hibaellenőrző-javító mezőből 4 bájtot használ a rutin, és meg tudja állapítani, hogy a többi 28 bájt (tehát a hasznos 24 bájt és a hibajívató mező maradék 4 bájtja) hibátlan-e, és ha nem, akkor egy, azaz egy bájtnyi hibát tud kijavítani! Két hiba esetén (ha valóban csak két hiba van)egyes lejátszók ebben az első hibajavító körben ki tudják javítani mind a két hibát, de mivel nem különböztethető meg, hogy valóban csak kettő, vagy több hiba volt-e, ezért ez az eljárás rosszul sülhet el (az elméletileg jobb hibajavítás rosszabb eredményt adhat, mintha nem is javítottuk volna az adatot - tehát a túlbiztosítás sem jó). A hibajavítás második menetét segíti az a tény, hogy a CD lemezen a lejétszáskor logikailag egymáshoz tartozó adatok nem ugyanabban a fizikai sorrendben követik egymást, mint azt sejtenénk, hanem egy bizonyos algoritmus segítségével el vannak keverve egymás között. Ennek köszönhetően egy-egy nagyobb karcolás nem tud teljes, hosszabb, logikailag összetartozó adatmezőket tönkretenni, mert az egymáshoz tartozó adatok nem közvetlenül egymás mellett, hanem a lemez íve mentén, szélesen elszórva találhatóak meg. Így valószínűleg jobban kijavítható egy-egy nagyon durva sérülés, mert nem egy komplett adatmezőt semmisít meg, hanem sok-sok adatmezőnek okoozott egyenként pici kárt (ami feltehetőleg még javítható). A hibajavító adatok is ugyanígy, eltolással vannak elhelyezve a frame-ekben, tehát egy-egy fizikai frame-en belül nem az adott 24 bájthoz tartozó hibajavító bájtok találhatóak meg (nem sok értelme lenne, hiszen ha egy fizikai sérülés miatt a frame hibás, akor valószínűleg a benne található 8 hibajavító bájt is hibás lenne) hanem a szomszédos frame-eké, szérszórva. Nem ragozom tovább, elég legyen annyi, hogy egy meglehetősen bonyolult művelet segítségével a maradék 4 hibajavító bájtnak köszönhetően a frame-en belül további 4 hibás bájt mutatható ki és reparálható meg. Ha ennél több van egy frame-ben, akkor ott már nincs mit tenni, hacsak a lejátszóban nincs egy - relatíve - nagyméretű, több kilobájtos RAM, amelyben számos beolvasott frame tárolható ideiglenesen. Ez további, utólagos trükkökre ad lehetőséget. A memóriának köszönhetően a második körben kijavított, az első körhöz tartozó ellenőrző kódok segítségével esetleg az eredetileg két hibánál többet tartalmazó framek is visszanyerhetőek, de ehhez ugye meglehetősen sokáig a memóriában kel tartani a rég dekódolt frame-ket, hogy amikor a második hibajavító kör kezdődik, akkor alkalomadtán vissza lehessen nyúlni, utólag újraolvasni a már feldolgozott, hibás adatokat - most már helyesen! Amúgy márkásabbnál is márkásabb lejátszók mindenféle egyedi megoldást használnak az ilyen problémékra, több-kevesebb sikerrel. A dekódolás ugyanis real-time, azaz valós időben történik, ami kissé megnehezíti az összetettebb hibajavítást.
Az Audio CD szabványnak tehát itt a gyengéje. Mert mi történik akkor, ha ez a hibajavítás nem elegendő, tehát még több hiba van a lemezen? Olyankor, kérem szépen, interpolál a lejátszó, azaz a hibádzó, hiányzó adatmezőt az azt megelőző és az az követő olvasható adatokból kikövetkezteti, arra építve, hogy ugyebár a zenei hanganyag meglehetősen harmonikus - tehát nagy valószínűséggel az átlagolás nem fog feltűnni. Ez így is van, de ha az interpolációval megbecsült adatok mennyisége elér egy bizonyos szintet, akkor bizony a zenei hanganyag erősen tompul, jellemzően eltűnnek a markáns részletek, laposodik a hangkép.
Az Audio CD lemezek hibajavítása olyannyira gyenge, hogy amikor a CD-ROM szabvány, azaz a számítógépes adattároláshoz használatos CD formátum megszületett, akkor kénytelenek voltak drasztikus lépéseket tenni a pontos olvashatóság érdekében.
Emlékezzünk, az adatok 33 bájtosával érkeznek, ebből 24 bájt marad az Audio CD esetén, mint hasznos állomány. A már említett adatszétszórás miatt a frame-ket logikailag tovább kellett csoportosítani, ezért 98 frame együttesen alkot egy szektort az Audio CD és az adatlemezeken egyaránt. Most már valószínűleg ismerős számok jönnek, mert rögtön látható, hogy egy szektor ezek szerint 32 bájtot tartalmaza kétmenetes, alacsony szintű hibajavítás előtt. Ebből ugye 24 marad meg, tehát 98x24 = 2352, jééé, tényleg ennyi a hasznos adat egy-egy Audio szektorban. Ez gondolom most már sokaknak ismerős szám. Említettük, hogy ez a 2352 bájt még tartalmazhat hibákat. Ezek a hibák az Audio CD lejátszásakor szerencsés esetben eltűnnek az iterpolációs trükk és a fülünk tökéletlensége folytán (persze egyéni képesség, hogy ebből ki mennyit hall meg), de egy szánítógépes adat nem helyettesíthető, pótolható ilyen módszerekkel - egyetlen bit eltérés is használhatatlanná tehet például egy programfájlt - tehát további hibajavítás kellett. Ezért a 2352 bájtból még további adatmezőket különítettek el a hibák javítására, így maradt a szabványos 2048 hasznos bájt szektoronként.
Ha az Audio CD lemez olyan tökéletesen dekódolható digitális formátum lenne, mint ahogy azt Ti állítjátok (tisztelet a kivételnek) akkor miért kellett a számítógépes adatok tárolásához további jelentős mennyiségű adatot hibajavításra használni? Kezditek már kapisgálni?
Amikor megírsz egy írható CD-R lemezt, a lézernek az írási sebesség növelésével egyre kevesebb ideje marad egy-egy pit létrehozására. Kevesebb idő alatt a lézerintenzitás növelésével és a jobban reagáló hordozórétegekkel sem lehet ugyanolyan optikai minőségű jeleket égetni, mint lassan. Az írható lemezek spirális nyomvonalának eltérése, apró torzulása a gyorsabb írással kombinálva egyre rosszabb alakú piteket eredményez, az ilyen lemezek olvasásakor a dekóder kétségbeesetten igyekszi "sávon" tartani az olvasó lézert, nem mindig teljes sikerrel.
Tehát a gyorsabb írás esetén nem a digitális adat fog különbözni a megírt lemez és a forráslemez között, hanem az elkészített lemezen található optikai jelek lesznek gyengébbek.
Audio CD esetén ezek a gyengeségek pedig a dekódolás során sokkal kevésbé javíthatóak, mint amikor adatlemezeket olvasunk, így a zenei lemezek lejátszásakor az ilyen problémás területeken a lejátszó többet kényszerül hibajavításra, javíthatatlan hibák esetén pedig interpolációs adatpótlásra, ami nagyon-nagyon ronthatja a zene minőségét, a hangkép harmóniáját. Ez nem csak szubjektív vélemény, ez műszerrel kimutatható.
Egy újságcikkben olvastam, hogy pl. a budaörsi MC&CD gyárban a Koch féle analizátort használják erre a célra, de van olyan mastering üzem, ahol speciális célszoftvert használnak (az Eclipse Data cég Image Suite programja a legjobb). Ezzel programmal például egy-egy Plextor olvasóval, 1x-es sebességű beolvasás (!) során tesztelik a lemezeket, amelyeket sokszorosítás gyanánt behoz egy-egy ügyfél.
Az Audio CD lemezek gyors égetése miatt bekövetkező minőségromlása tehát nem a képzelet műve, nem szubjektív dolog, hanem kőkemény tény, amit mindenkinek el fogadnia, aki megérti, hogy ennek valós FIZIKAI és MATEMATIKAI alapja van. Csak egy példa: nemrég megjelent egy SCSI csatolású Plextor író (pedig a kommersz piacra már csak ATAPI-t gyártanak). Szép fekete az egész meghajtó (extra cool!), speciálisan csak mastering célokra lett fejlesztve stúdiók részére - az ára is többszázezer forint, pedig egy "szimpla" író. Miért ilyen drága ez a "Plex Master" nevű cucc? Azért, mert a specifikációja szerint kiemelkedő minőségű Audio CD írásra képes - de kapaszkodjatok meg, csak akkor, ha 1x-es sebességgel írnak vele!
Nyilván egyénileg eltérő, hogy ki és mikor hallja meg ezt az elkerülhetetlen minőségi veszteséget - sokat számít a lejátszó és a környezet is. Meg kell mondjam, nem kell audiophilnek lenni ahhoz, hogy ezt kihallja valaki - én magam sem gondoltam régebben, hogy ez kézzelfogható jelenség, de műszeresen is láttam, és a saját fülemmel is halottam (és hallom nap mint nap) a különbségeket. Ez tény."
(
https://forum.hwsw.h...0#entry1429130_ )