Onderzoek naar onbrandbare bestanden bij Digit-Life

De Russen van Digit-Life hebben een uitgebreid verhaal gepubliceerd waarin wordt onderzocht waarom een bepaald filmbestand niet correct naar een cd-r geschreven kon worden. Van de 79 geteste cd/dvd-drives kon slechts circa 33 procent het bestand correct lezen terwijl de overige spelers allemaal de mist in gingen. Na een stapel experimenten komt de oorzaak aan het licht. Gegevens worden op een cd niet op exact dezelfde manier gebrand zoals ze op de harde schijf staan. Alle blokjes data op een cd worden bijvoorbeeld voorafgegaan door een zogenaamde sync header die ervoor zorgt dat de cd-drive zijn laser goed kan positioneren. Tevens wordt de data zelf door een zogenaamde scrambler gehaald.

Het blijkt dat hierdoor, met een flinke portie pech, de gebruikersdata ook sync headers kan bevatten die veel cd/dvd-drivers foutief herkennen als het begin van een nieuwe sector waardoor het bestand niet gelezen kan worden. De kans dat dit gebeurt is echter extreem klein, maar desondanks zou het niet nodig hoeven te zijn met een slimmere firmware. Een interessant verhaal voor ieder die geïnteresseerd is de werking van cd/dvd-drives en computers in het algemeen.

Reacties (28)

[Verwijderd]

een onbedoeld nieuwe beveiliging?

[Sprite_tm]

(Hmm, het uitgebreide verhaal lijkt een neplink te zijn )


Ik denk het niet, het lezen is namelijk een probleem, niet het branden. Dan zou je dus de originele CD ook al niet kunnen lezen.

Edit: Of wel... Ze gooien die foute sync-headers etc gewoon in een niet-gebruikt bestandje en een 1-op-1-kopie is onmogelijk. Wat de meer geavanceerdere cdrom-rippert natuurlijk niet tegen zal houden tho'

[XthinkZ]

Ik kan me een soortgelijk geval herinneren dat bijvoorbeeld bepaalde data toevallig dezelfde gegevens hadden om een modem offline te gooien.

Het kwam erop neer dat het bestand nooit te verzenden/downloaden viel.

Misschien dat iemand anders dit kan bevestigen?

[Verwijderd]

Klopt! dat werd ook gebruikt om mensen offline te gooien; indien de combinatie "+ + +" naar het modem werd gestuurd dan ging deze in Hayes command mode, waarna je met een simpele "ATH" de verbinding kon verbreken.
Dit werd dan in een Ping naar de computer in kwestie gestuurd, die dan een Ping reply terugstuurt met diezelfde data erin.. dag verbinding.

[scsirob]

Leuk verhaal, maar het klopt niet... Na +++ moet nog 1 seconde stilte komen voordat een modem in Hayes command mode komt. Dat soort delays kan je niet in een ping pakketje verwerken.

Als je verhaal wel zou kloppen dan zouden alle modem gebruikers van het web geschopt worden als ze deze pagina lezen waarop ik nu "+++ATH
<NO CARRIER>
OK

[dmantione]

Dit geldt niet voor alle modems. Hayes had een patent op die 1 seconde wachten, dus tot een paar jaar terug moest je als modemfabrikant aan Hayes betalen als je die 1 seconde wilde implementeren.

In plaats van die 1 seconde scanden veel modems op de combinatie +++AT , welke dus makkelijker te misbruiken is.

[Verwijderd]

Dit is de goede link, die in de post lijkt alleen op een link.

Kan er een link naar die testfile worden opgenomen in het stuk ? Ben best benieuwd ernaar, en wil zelf ook gaan expririmenteren.

Al gevonden, staat in het artikel zoek naar naar badvideo.avi (mag er niet naar deeplinken)

[Chatslet]

Ik zie net overigens in die link bij de tabel met branders dat de NEC 1300A en de Pioneer A06 dezelfde chipset hebben mischien een beetje offtopic maar mischien dat de NEC 1300 dus ook binnenkort dual layer kunnen fikken met een firmware update.

[TD-er]

het was al wel langer bekend dat gecomprimeerde data vaker problemen kan geven, wanneer het teruggelezen moest worden.
Daarom ben ik dus ook zo'n fan van rar, daar je die kunt repareren.

Maar toch mooi dat er een verklaring voor gevonden is... namelijk dat gecomprimeerde data nagenoeg random is, waardoor het een grotere waarschijnlijkheid heeft net die ongelukkige combinatie van bytes te bevatten die lijkt op data die het opslagmedium zelf gebruikt.

[Verwijderd]

accu burn van www.arrowkey.com zorgt dat alles gebrand wordt zoals ze op je hd staan

[TD-er]

volgens de onderzoekers gaat het er ook om dat de file niet goed gelezen kan worden.
Het schrijven is dus geen probleem.

edit:
OK, ik heb even de Accuburn details bekeken en het lijkt erop dat dit progsel een soort van extra ECC-laag tussen het filesysteem en de feitelijke bits op de cd/dvd legt.
Ik ben het stuk nog aan het doorlezen, maar vond een rectificatie van mijn post wel op z'n plaats

edit2:
Het is dus meer bedoeld voor backupdoeleinden en niet zomaar voor gewoon gebruik.
Dit programma schrijf een blokje data en leest het gelijk weer terug ter verificatie.
Voor het specifieke probleem van dit nieuws-bericht biedt het dus geen oplossing, want in zo'n geval zal ofwel de secter steeds opnieuw geschreven worden (totdat de disc vol is) of de brander kan het wel goed lezen, maar een andere cdspeler niet en dan is het nog steeds geen oplossing.
Daarnaast lijkt me dit schrijfproces toch een vrij grote belasting voor de brander-hardware.

[Gody]

bijvoorbeeld nero kan gegevens ook controleren op correctheid na het branden. Die optie staat bij mijn backups op cdrw's standaard aan. backups ver-bakken is niet gewenst.

[TD-er]

In het stukje waar deze nieuwspost over gaat, staat dat ze er op die manier ook achter kwamen dat het mis ging, namelijk dat de nero-compare-functie telkens aangaf dat het mislukt was.

kortom je hebt enige zekerheid dat het goed is gegaan als de compare goed gaat, maar wanneer die fout gaat heb je dus de mogelijkheid dat je zo'n vervelende file te pakken hebt of dat er iets met je medium mis is.

[Tom_G]

Ik heb in het verleden al massaal mogen cd's weggooien met divx films op.

Zou dat er ook iets mee te maken hebben? Vaak kreeg ik bij het kopieren naar hd een foutmelding van redundatie of redundactie, ik weet het niet meer exact. In elk geval, de file was zowat onbruikbaar.

[Noel]

Gewoon crappy media of crappy cd-drive. Crappy media icm hoge schrijfsnelheden is ook niet bevorderlijk voor je data.

[BamSlam_]

En nog een goede reden om je data niet op CD's of DVD's op te slaan, die na een paar jaar niet meer leesbaar zijn, maar gewoon op een extra harde schijf te backuppen!

[VisionMaster]

[00ps bedoelt als nieuwe post niet als reactie]
Klinkt als op te lossen met een driver of firmware update om deze data beter te scheiden in data en headers van data.
(of denk ik nu weer te simpel als programmeurtje van dienst)

[bobo1on1]

En nog een goede reden om je data niet op CD's of DVD's op te slaan, die na een paar jaar niet meer leesbaar zijn, maar gewoon op een extra harde schijf te backuppen!

Die na een paar jaar ook weer kaduuk is

[marsattacks]

Grappig.. dit verhaal komt me bekend voor. Ik heb ooit een zip file gehad die m'n dynalink modem weigerde te FTP-en. Als ik het toch probeerde hing m'n internet verbinding. Alleen in uuencode vorm kon ik het uiteindelijk versturen.

[XthinkZ]

Kijk, mijn geheugen laat me gelukkig niet in de steek.

Het komt bijna nooit voor, maar als je het een keer tegenkomt, loop je je echt suf te zoeken waar het probleem is, en uiteindelijk blijkt dat het bestand code bevat die de modem interpreteerd als een bepaalde commando.

Het is dus net zoals het nu dus bij dit bestand het geval is, je met een probleem komt te zitten waarvan je niet een twee drie weet waar je het moet zoeken.

[Verwijderd]

ja, ik had ook ooit eens een tijdje "Doei! +++ATH" aan het eind van mijn mail staan. En ik snapte maar niet waarom mijn internetverbinding er steeds uitklapte :-)

[seweso]

Maar dan heeft iemand toch een bagger protocol/standaard bedacht om cd's te branden of heb ik het nou verkeerd?

[hardwareaddict]

Philips bedoel je?

Nee hoor zo bagger is het echt niet. Je moet namelijk de prijs per megabyte die de cdrom levert sterk in de gaten houden.

Overigens is dat ondertussen ook al te duur, op dit moment is een harddisk per megabyte omgerekend vrij gunstig aan het worden.

Edoch een aantal jaar geleden kon er eigenlijk niks op tegen de prijs per megabyte van cdroms, dus zo onzinnig is dit protocol niet gezien het succes

[TD-er]

het is ook niet zo dat alle spelers een dergelijke file verkeerd inlezen, oftewel het protocol hoeft niet percee bagger te zijn.
Het laat alleen blijkbaar te veel ruimte voor vrije interpretatie van de mensen die de firmware schrijven van de lezers/branders.
Wanneer die bij het lezen van een bepaalde sequentie van bytes er klakkeloos vanuit gaan dat ze aan het begin of eind van een sector zijn, kunnen ze er dus wel eens naast zitten.
Een extra check zou dus zinvol zijn, maar dan loop je de kans dat je drive wat langzamer is, of de programmeurs hebben er gewoonweg niet aan gedacht.
Ik ben eigenlijk wel benieuwd welke drives (merken) er wel last van hebben en welke niet.
Ik vraag me dan ook af in welke groep de Plextors zitten en of er bijvoorbeeld een onderscheid is tussen de SCSI-series en de IDE-series (mogelijk dat ze bij de SCSI-tak dus meer aandacht eraan besteden...)

[Compunologist]

Het zal wel aan mijn suffe zondagmiddaghoofd liggen maar ik vroeg me toch echt af of mensen bezig waren met het creëren van onbrandbare bestanden toen ik de titel zag. Dat lijkt me toch vrij lastig...

[imagica]

Dit is helemaal niet onzinnig aangezien een Glasmaster gemaakt wordt uit een originele cd of Image op DLT, de productie is een pers methode en geen brand methode dus als je bestanden kunt maken die niet of maar 1 keer te branden zijn heb je een hele goede kopierbeveiliging (meestal voor eventjes)