Riverwind skrev:
Ghammel & Suhr skrev:
Riverwind skrev:
Ok, så har jeg lige prøvet med data. Jeg har brændt med 40x via image i Nero, og har lige prøvet at sammenligne (binært) flere filer fra originalen med de samme filer på kopien.
De er nøjagtig ens, så ikke overraskende har det nok noget at gøre med den manglende eller upræcise inddeling af sektorerne på audio-cd'erne.
Jeg har kun én CDR tilbage. Tror jeg vil bruge den til et forsøg med EAC senere.
|
|
|
Det anede mig. Har du mulighed for at aflæse ToC...? (se evt. mit svar til micjac foroven) Med høvisk hilsen G&S |
|
|
Gider ikke lige prøve med EAC nu, men har læst i deres forum, og kan udlede, at for at lave en eksakt kopi kræves det at man laver noget offset-beregning mht. read og write, som micjac skrev. Det lyder som om det skulle være muligt at få en 1:1 audio-kopi, når man læser derinde, men nu vil jeg efterhånden se en, før jeg tror på den 
Prøv lige at kigge nærmere på det, når du kommer derind. |
|
|
Yeps, så er der set lidt nærmere på EAC - derfor nedenstående beskedne fodnote.
Som tidligere udgylpet herfra, så går programmet alene ud på, at enten omgå eller kompensere for de problemer, der uværgeligt opstår ved audio extraction.
Eller sagt på almindeligt dansk: EAC kan kun lave "perfekte" (ikke perfekte, desværre) konversioner fra track.cda til track.wav. Nothing else.
At der så findes en brænde-funktion (det gør der i hvert fald i min version), eliminerer ikke de tidligere omtalte problemer omkring MMC-1/2, etc.
Hermed følger nogle løsplukne citater:
Fra EAC homepage:
"...'Sample Offset' is another new feature of EAC, it will help to always get the same WAVs compared to a different reader and to prevent generation losses..."
- altså for at gøre det muligt, at tage en kopi af en kopi (2. generation kopier byder på visse veldokumenterede problemer...hvorfor mon...?)
Og der fortsættes samme sted fra:
"...Furthermore, drives that have jitter are unable to position their heads correctly.
A drive's characteristic offset can be found automatically from the CD from on the list of reference CDs. Because of the mentioned jitter error the value given back is also not 100% sure.
...it seems that also big CD manufactures also do not always press the same offset on their CDs..."
Så hudt jeg visker består f.eks. et ISO image af sektorer á 2.048 Bytes (jvf. specs). Dermed er der en mindre divergens, set i forhold til CD-A...:
"...16-bit stereo samples require 4 bytes per sample, so there's 2352/4 = 588 samples per sector. At 75 sectors per second, that's 44100 samples per second (44.1KHz).
98 frames of 24 bytes are combined to form a 2352-byte sector and 98 bytes of subcode data. The sector is assembled from F1 Frames, which are byte-swapped, shuffled, and run through a descrambler. The purpose of the scrambler is to reduce the likelihood that regular bit patterns will induce a large digital sum value.
It should be pointed out that the 2352-byte sector is the smallest unit most CD-ROM drives will allow software to manipulate. It's only after all of the above that low-level CD-ROM operations, like "RAW DAO-96" reads and writes, begin. This is why making a "bit-for-bit" copy of a disc is tricky.
A sector on an audio CD holds 2352 bytes of data. 16-bit stereo samples require 4 bytes per sample, so there's 2352/4 = 588 samples per sector. At 75 sectors per second, that's 44100 samples per second (44.1KHz). At this point, the processing for an audio CD is essentially complete. CD players feed the samples through a DAC (or S/PDIF connector) and eventually out to the speakers, and send the subcode data to the front panel controller so it can update the HH:MM counter and track number.
A sector on a CD-ROM holds 2048 bytes of user data, leaving 304 bytes for other purposes. Every data sector begins with a 16-byte header:
* 12-byte sync field (00 ff ff ff ff ff ff ff ff ff ff 00)
* 3 byte address (minute, second, fraction (1/75th) of a second)
* 1 byte mode
..."
(sakset fra www.cdrfaq.org/faq02.html#S2-43-4).
Og fra EAC FAQ'en:
"...Q:Audio extraction is purely digital, how could unremarked errors occur?
A:The data transmission itself is purely digital and also the data stored on the CD. But the Red Book standard (standard for audio CDs) is very weak and only little error correction will be performed in the drive. So on bad CD-ROM drives it is possible that you receive erroneous results..."
Hvilket får mig til at bevæge mig ind på subcodes i forhold til jitter, gnæk-gnæk - jitter!
Det viser sig nemlig, at ved CD kopiering er jitter en langt større synder, end andre her på stedet har ment i denne eller lignende tråde.
Som jeg før har været inde på, så skrives der ikke en komplet TOC ved kopiering af en CD. Dette er format bestemt (CD-R og MMC-1/2 protokollerne).
Men den originale CD's TOC indeholder information om diverse Subchannels (typisk Q-kanalen), der igen indeholder information om den nøjagtige sector placering af Audio data.
Får man ikke alle de originale Subchannels med, får man dermed heller ikke den nøjagtige information omkring placering af sektorer med - dette med kraftig fejlkorrektion i afspilleren som følge, og dermed ringere lydkvalitet. Egentlig ret logisk, ikk'? ;-)
Den fulde TOC's henvisninger til Subchannels er derfor essentielle, at få med.
Yderligere har den nævnte Sub code den funktion, at der skabes en synkronisation mellem Subchannel og Audio. Alt dette er ovenordnet bestemt af TOC, der jo indeholder den nødvendige info om, hvor de forskellige ting befinder sig i filsystemet (TOC > Sub code > Audio data).
Såfremt der mangler den ovenstående Sync, vil dette forårsage yderligere jitter, da placeringen af data dermed ikke er givet på forhånd, set i forhold til en original Audio CD, der indeholder en fuld TOC. En fraktion af dette kan ses på www.cdrfaq.org/faq02.html#S2-23.
For nu at forplumre det hele yderligere, så har et CD-ROM drevs cache også en væsentlig indflydelse på jitter, da jitter som bekendt er Time/Domain fejl. Altså når data ikke når det rette sted hen til den rette tid ( og IKKE "forvrængning", som nogen mener - og nej, der er heller ikke tale om forvrængning af data, kun af tidsspektret).
Da cach'en i et CD-ROM drev normalt læser i såkaldte "chunks", er der derfor ikke nogen garanti for, at det er de rette data, der læses på det rette tidspunkt. Derfor vil der uværgeligt opstå jitter (eller Time/Domain errors) ved læsning fra drevets cache.
Yderligere har CD-ROM drev ikke den samme indbyggede fejlkorrektion, som audio drev har. Dette foregår jvf. specs i stedet i den pågældende platforms software.
Derfor VIL vejen fra CD-ROM til harddisk være jitterbefængt, like it or not. Og mængden af jitter afsløres ikke ved en binær sammenligning, da det ikke datalogisk defineres som værende fejl i data. At det så stadig er fejl, er en anden og i særdeleshed hørbar ting.
Altså:
Det kan ikke lade sig gøre, at lave en 1:1 kopi af en audio CD på en computer, da formaterne ikke tillader dette.
Og kan man ikke høre forskel på originalen og kopien, så bør man enten få sine øren skyllet - eller skylle anlægget ud!
Hvis der på trods af ovenstående stadig skulle være nogle tykpandede tvivlere presente, så kan jeg kun anbefale en lettere til middelsvær Arnbitter marinade sammen med en grundig og perceptiv læsning af f.eks. Andy McFadden's CD-Recordable FAQ: www.cdrfaq.org.
Der afgår hermed fortjente og velplacerede Ris & Ferle hilsner til numsi og hans veninde, BjarneArne, institut for datalogi, Aalborg universitet.
Med hilsner fra sommerresidensen
G&S