Het Lab: Archiveren PC-Active cd-roms

Henk van de Kamer

Vanaf nummer 9 – het blad kreeg pas zijn huidige naam met nummer 12 – werd maandelijks een 5¼-inch single sided, double density floppydisk [2] bijgevoegd. Uiteraard werd de 360 kilobyte (!) al snel te weinig en stapten we met nummer 32 over op de 3½-inch double sided, double density variant met dubbele opslagcapaciteit. Met nummer 67 werd deze opslagcapaciteit wederom verdubbeld door de overstap naar 3½-inch double sided, high density. Dit diskettearchief heb ik eind 2005 gearchiveerd en is op de cd-rom bij nummer 187 verspreid.

cd-rom
Bij de nummers 55 en 63 had een deel van de oplage een cd-rom. Gezien de enorme ruimte is altijd gesteld dat we voor kwaliteit en niet voor kwantiteit gingen. Tijdens deze experimenten werd duidelijk dat nog lang niet iedereen een cd-romspeler had en dat zelfs het deels vullen een complete dagtaak is.

In de zomer van 1995 werd hard gewerkt aan de derde cd-rom voor de 75^e jubileumuitgave. De eerste twee zijn door een externe partij gemaakt, deze werd op de redactie samengesteld. In die tijd was ik met een clubje enthousiastelingen een cd-rom voor de toenmalige HCC IBM-PC gebruikersgroep aan het samenstellen. Het is dan ook niet verwonderlijk dat ik als aanstichter werd benaderd om eens te praten over een maandelijkse cd-rom. En zo begon ik begin september als kersverse cd-romcoördinator bij PC-Active.

Na nummer 100 had ik het vullen van een cd-rom wel gezien en waren er genoeg andere activiteiten binnen de uitgeverij om mijn tanden op stuk te bijten. Uiteindelijk was ook de tijd van de cd-rom – een paar nummers hebben een DVD – voorbij en zat bij nummer 260 de allerlaatste.

Archiveren
Midden vorig jaar heb ik een aantal beslissingen genomen over hoe ik de tijd tot mijn pensioen ga vullen. Eén van die beslissingen was de verkoop van mijn huis. Aangezien ik de verbouwing vanwege de kredietcrisis nooit heb kunnen afmaken, was duidelijk dat dit niet zo snel zou gaan. Nu heb ik geen haast, ofwel dit is niet echt een probleem. De afgelopen decennia heb ik veel verzameld en dat is wel een probleem als de tweede beslissing een Tiny house betreft. De derde beslissing is dat ik (computer)techniek wil blijven uitzoeken en daarover vertellen. Bij het opruimen moet ik daar dus rekening mee houden…

PC-Active cd-roms
De rest van deze aflevering gaat over de 311 [3] – met nog eens twee- tot vierhonderd andere – PC-Active cd-roms. De snelle rekenaars hebben al geconcludeerd dat met 184 reguliere cd-roms een deel van de collectie dubbel zal zijn. Dat is op zich goed, zoals het diskettearchief heeft aangetoond. De tool voor het archiveren is het Linux dd commando. Deze leest ongeacht het bestandsformaat van begin tot einde bytes en schrijft deze weg. Als er halverwege een leesprobleem is, breekt het standaard af:

hvdkamer@nestorix:~/cdrom$ dd if=/dev/sr0 of=pcacd107.iso

dd: error reading '/dev/sr0': Input/output error

1324456+0 records in

1324456+0 records out

678121472 bytes (678 MB, 647 MiB) copied, 210.715 s, 3.2 MB/s

Ai? Niet helemaal. Er zijn meer redenen waarom dd met een foutmelding afbreekt. Bijvoorbeeld als de hardware niet correct het einde aangeeft. In dat geval probeert dd een volgende blok – standaard 512 bytes – te lezen, waarna de hardware tot de ontdekking komt dat die niet bestaat. Gelukkig kan de grootte van de meeste bestandssystemen opgevraagd worden:

hvdkamer@nestorix:~/cdrom$ /sbin/isosize /dev/sr0

678123520

Het verschil tussen deze twee is exact 2.048 bytes en dat is de standaard blokgrootte van het iso9660 [4] bestandssysteem. Ofwel dd kan het allerlaatste blok niet vinden. Dit zag ik bij veel meer cd’s in een bepaalde periode en is mogelijk een bug geweest tijdens het branden? In een vluchtige controle lijken de gemaakte images gewoon te werken, maar mogelijk is het allerlaatste bestand op de cd beschadigd.

Audio track
Een andere geldige reden waarom dd afbreekt, zijn cd’s met een datatrack en één of meer audiotracks. De datatrack bevat blokken van 2.048 bytes en de audiotrack blokken van 2.352 bytes. Data op de cd is ook 2.352 bytes groot, maar 304 hiervan bevatten een extra laag van foutdetectie en correctie. Voor audio is een omgevallen bit niet erg, voor computerdata wel. De logica op de cd-romspeler weet of iets data of audio is en geeft dus de juiste hoeveelheid terug. En daar kan dd niet goed tegen. Ofwel, na het inlezen van de data – dit is over het algemeen de eerste track – gaat het mis.

Om de audiotrack te archiveren heb ik voor een drietal cd’s – nummers 78, 79 en 88 bevatten een audiotrack – de cd’s ingelezen met cdrdao. Dit programma dwingt de cd-romspeler om alles als audio te behandelen. Vervolgens kunnen met bchunk ook .iso en .wav bestanden geëxtraheerd worden. De eerste hoeft niet exact gelijk te zijn aan de met dd gemaakte versie, maar zolang het groter of gelijk is aan wat isosize zegt, ga ik niet klagen...

Indelen

Uiteindelijk heb ik van alle cd’s met isosize de grootte opgevraagd en vergeleken met dd. Op basis van succes of falen heb ik alle cd’s ingedeeld in vier categorieën met een status van 0 t/m 3 (zie figuur 1). Alle ruwe data is tevens vastgelegd in een LibreOffice spreadsheet. De cd’s lagen door het hele huis verspreid en omdat de locatie van invloed kan zijn op de kwaliteit heb ik de cd-roms per vindplaats gelabeld. De cd-roms uit de Axis Storpoint-test waren bijvoorbeeld keurig in kartonnen enveloppen ingepakt en zijn waarschijnlijk zo goed als nieuw. Ook de collectie in de bladen zelf is goed, al waren daar sommige in de lijm van de envelop gezakt. Gelukkig was dit deze te verwijderen. De losse cd’s hebben in een krat op mijn werkkamer gelegen. Nog erger zijn de cd’s uit het magazijn. Een deel zat in een jewelcase, maar ook die zaten onder het (bouw)stof. Ook hier alles voorzichtig schoongemaakt.

Figuur 1: Hoe betrouwbaar is de gemaakte image?

Een image krijgt een 0 indien dd niet afbreekt en de isosize kleiner of exact gelijk is aan de bestandsgrootte. Inderdaad heeft een hele serie cd’s op het einde de nodige extra geheime (?) data. Als dd afbreekt en de grootte van de image is minimaal de grootte van isosize aangeeft minus 2.048 bytes – voor cd-roms met audio track moet dit ook gelden voor de grootte van bchunk – krijgt de image een 1. Deze zijn waarschijnlijk in orde, maar er is een kleine kans dat het laatste bestand op diens einde 2.048 bytes mist. Tot slot ontdekten we dat de DVD bij nummer 241 geen iso9660 maar udf als bestandssysteem gebruikt. Het werkt, maar desondanks vind ik dit twijfelachtig ofwel ook een 1. Als dd afbreekt en het geheel beduidend kleiner is dan we via isosize verwachten wordt het een 2. Deze images zijn waarschijnlijk onbruikbaar, maar zolang er geen intact exemplaar is in ieder geval beter dan niets...

Tot slot
Zoals gezegd zijn 311 cd-roms in Het Lab gevonden. Twee exemplaren van nummer 77 lezen beide goed in, maar de uiteindelijke grootte is verschillend. Nu is de isosize in beide identiek en kleiner dan de image, ofwel ook hier ga ik niet klagen. Omdat er geen extra laag aan foutcorrectie in de audio tracks aanwezig is, kan de uiteindelijke .wav op een paar bits verschillen. De drie nummers 78 en vier nummers 88 zijn desondanks identiek. Alleen de twee exemplaren van nummer 79 verschillen.

Uiteindelijk breken zes exemplaren af tijdens het lezen. Eén daarvan leest zelfs niets en nader onderzoek leert dat aan het begin – midden cd – een luchtbel is ingesloten! Vier hebben minimaal één wel correct ingelezen dubbelganger, maar helaas geld dat niet voor nummer 162. Tot slot heb ik geen exemplaar van nummer 139 gevonden. Ik hoop dat een lezer deze wil aanvullen. Het complete archief is bijna 130 GiB groot en momenteel wordt op de redactie nagedacht hoe mijn cadeau verspreid gaat worden.

Infolinks

[1] www.hetlab.tk/afleveringen/hetlab-199804

[2] https://en.wikipedia.org/wiki/Floppy_disk

[3] www.hetlab.tk/algemeen/pc-active-cd-rom-archief-2

[4] https://en.wikipedia.org/wiki/ISO_9660