Physikalische Lesekopfposition eines DVD-Laufwerks ermitteln

In dieser Linux-Ecke dürfen nur Themen rund um Linux geschrieben werden.
Beiträge, die plattformübergreifend sind, gehören ins 'Allgemein'-Forum.
Benutzeravatar
Domino
Beiträge: 22
Registriert: 21.12.2015 21:28
Computerausstattung: Centrino 2x2GHz, GeForce Graka
Linux 3.16

Physikalische Lesekopfposition eines DVD-Laufwerks ermitteln

Beitrag von Domino »

Moin!

Habe ein einfaches Leseprogramm, das Daten von verkratzten DVDs einliest.
Datei öffnen geht mit z.B.

Code: Alles auswählen

OpenFile(#PB_Any, "/media/domino/Filme/VIDEO_TS/VTS_01_2.VOB")
ganz regulär. Auch Positionieren läuft mit FileSeek() und Lesen mit ReadData() ganz gut.

Leider benötige ich jetzt die physikalische LASER-Position als Radius zum Scheibenmittelpunkt an der aktuellen Lesestelle einer Datei, um an dieser Stelle ggf. polieren zu können. Da ich nicht davon ausgehen darf, daß die Dateien auf der Scheibe alphabetisch angeordnet sind (habe etliche in „analphabetical order“), kann ich die Rechnerei über Durchmesser relativ zum Gesamtdatenvolumen der Scheibe usw. gleich wieder vergessen.

GNU/Linux hält Infos in etlichen Dateien wie /proc/cpuinfo usw. bereit, aber hier stehe ich wie der Ochs’ vorm Berg. Vielleicht geht es eleganter über die Linux-API, aber auch hier bin ich überfragt. Die Linux-API-Doku von Omi schweigt sich zu IO-Themen leider noch aus. Vollversion von PB ist vorhanden.

Weiß jemand von Euch, wie es am besten geht? Die Foren-Suche habe ich selbstverständlich bemüht, doch keine Lowlewel-Programmierung für Datei-IO auf GNU gefunden. Jeder Schubs in die richtige Richtung ist willkommen.

Danke vorerst!
Domino
____

Edit 2017-06-22 01:20 GMT:
Ein paar Infos habe ich aufgetan: ioctl() mit Kommando CDROMSUBCHNL könnte helfen, da es eine Struktur cdrom_subchnl zurückgibt und darin das Feld cdsc_trk möglicherweise die Sektornummer des LASERs enthält. Das ist zwar vage, aber sicherlich eine Überprüfung wert. Leider weiß ich immer noch nicht, wie ich die Aufrufe von PB aus anstoße. Jetzt erstmal heia machen. :D
Centrino 2x2GHz, GeForce Graka, mehrere Linux Mint u.a. mit Mate, Linux 3.16
Benutzeravatar
NicTheQuick
Ein Admin
Beiträge: 8675
Registriert: 29.08.2004 20:20
Computerausstattung: Ryzen 7 5800X, 32 GB DDR4-3200
Ubuntu 22.04.3 LTS
GeForce RTX 3080 Ti
Wohnort: Saarbrücken
Kontaktdaten:

Re: Physikalische Lesekopfposition eines DVD-Laufwerks ermit

Beitrag von NicTheQuick »

Also wenn es nur um's Polieren geht, wäre es glaube ich einfacher einfach die ganze DVD zu polieren. Und selbst wenn du den Radius in etwa herausfinden kannst, weißt du ja immer noch nicht wo auf dieser Kreisbahn mit dem Radius sich die Stelle befindet. Du hast ja keinen Anhaltspunkt wo die Spur startet.
Ich fürchte außerdem, dass sich das DVD-Laufwerk selbst um seine Spuren kümmert und das Betriebssystem gar nichts davon weiß, wo sich der Kopf nun befindet. Aber diese Aussage habe ich noch nicht verifiziert.
Bild
Benutzeravatar
ts-soft
Beiträge: 22292
Registriert: 08.09.2004 00:57
Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel
Wohnort: Berlin

Re: Physikalische Lesekopfposition eines DVD-Laufwerks ermit

Beitrag von ts-soft »

Niemals kreisförmig Polieren und immer von Innen nach Aussen. Das man die gesamte CD/DVD/BluRay poliert, sollte
wohl selbstverständlich sein.

Danach sollte sich die CD/DVD/BluRay wieder normal lesen lassen, so das die Frage von Domino sich eigentlich
erübrigt.
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Bild
SBond
Beiträge: 266
Registriert: 22.05.2013 20:35
Computerausstattung: armseliger Laptop, mit wenig RAM und noch weniger CPU-Leistung. ...und die Grafikkarte.... ....naja.. da male ich doch lieber selber.
Wohnort: nahe Wolfsburg

Re: Physikalische Lesekopfposition eines DVD-Laufwerks ermit

Beitrag von SBond »

hmm.... hat man nativ überhaupt die Möglichkeit, die Laser-Position zu ermitteln? Wenn dann kann es ja nur über eine Treiberfunktion gehen oder?
Ggf. kann man die Position über das Dateisystem der DVD ermitteln. Da muss doch irgendwo hinterlegt sein, an welcher Position (Sektor) sich z.B. die Datei X befindet. Mit der Sektorposition kann man ggf. den Radius berechnen.
41 6c 73 6f 20 77 65 6e 6e 20 64 75 20 73 6f 20 76 69 65 6c 20 4c 61 6e 67 65 77 65 69 6c 65 20 68 61 73 74 2c 20 64 61 6e 6e 20 6b 61 6e 6e 73 74 20 64 75 20 61 75 63 68 20 67 6c 65 69 63 68 20 7a 75 20 6d 69 72 20 6b 6f 6d 6d 65 6e 20 75 6e 64 20 61 62 77 61 73 63 68 65 6e 2e

:D
Benutzeravatar
Domino
Beiträge: 22
Registriert: 21.12.2015 21:28
Computerausstattung: Centrino 2x2GHz, GeForce Graka
Linux 3.16

Re: Physikalische Lesekopfposition eines DVD-Laufwerks ermit

Beitrag von Domino »

Vielen Dank schonmal, SBond! Genau über das Dateisystem sollte sich die benötigte Info holen lassen. Meine mitternächtliche Idee aus meinem Eröffnungsbeitrag konnte ich dann auch gleich wieder vergessen, da das Feld cdsc_trk vom Typ ubyte ist und erfaßt damit höchstwahrscheinlich nur die Liednummer einer CDDA (siehe red book, max. 99 Lieder).

So, meine Frage also in den Raum gestelt: Wie komme ich an die Sektornummer und -größe eines Mediums für den Start des Datenteils einer Datei? Das wird sich doch wohl noch über PB machen lassen! Per FileID() könnte das klappen, doch die PB-Hilfe schweigt sich wieder einmal aus, welche Adresse welcher Struktur genau zurückgegeben wird.

Hier im Forum führt die Suche nach „FileID(“ nur zu Quelltexten, die „FileID“ als Dateizeigervariable nutzen. Die PB-Funktion scheint niemand zu verwenden. „ImportC“ ist nur dann sinnvoll, wenn man die betriebssystemeigenen Header-Dateien gut kennt. Beispiel-Quelltexte sind rar und beantworten kaum offene Fragen. Warum gibt es nicht z.B. ein Paket von Include-Dateien, die man einfach in seine PB-Programme einbinden könnte und mit denen sofort Zugriff auf die Zillionen von Betriebssystemfunktionen möglich sind? Die muß man wahrscheinlich nach Betriebssystem (Windows, GNU/Linux, MacOS) trennen, aber das macht ja nichts. Wo finde ich diese Include-Dateien?

Gruß – Domino
Centrino 2x2GHz, GeForce Graka, mehrere Linux Mint u.a. mit Mate, Linux 3.16
GPI
Beiträge: 1511
Registriert: 29.08.2004 13:18
Kontaktdaten:

Re: Physikalische Lesekopfposition eines DVD-Laufwerks ermit

Beitrag von GPI »

Domino hat geschrieben:So, meine Frage also in den Raum gestelt: Wie komme ich an die Sektornummer und -größe eines Mediums für den Start des Datenteils einer Datei? Das wird sich doch wohl noch über PB machen lassen!
Die einzige Möglichkeit, die mir einfällt ist, die CD in "RAW-Mode" direkt sektorweise auszulesen und auch das Inhaltsverzeichnis selbst auszuwerten. Ich wüsste nicht, wozu man eine API bräuchte, die genau das macht. Das ist einfach eine Aufgabe des Betriebsystems/Dateisystems.

Du müsstest dich damit quasi mit den Dateisystem auf der DVD auseinander setzen.

Aber blöde Frage: Selbst wenn du das weist - woher willst du wissen, wo das jetzt wirklich auf der DVD ist. Da gibts kein Anfang und kein Ende.
CodeArchiv Rebirth: Deutsches Forum Github Hilfe ist immer gern gesehen!
Benutzeravatar
Domino
Beiträge: 22
Registriert: 21.12.2015 21:28
Computerausstattung: Centrino 2x2GHz, GeForce Graka
Linux 3.16

Re: Physikalische Lesekopfposition eines DVD-Laufwerks ermit

Beitrag von Domino »

So, Leute!

Habe mir nochmal einen weiteren Satz Hörner abgestoßen. Wollte das Problem (zumindest einen Teil davon) ganz einfach über Shell-Programme lösen und versuchte daher, inodes zu verwenden. Ich komme auch per

Code: Alles auswählen

ls -i1U /media/domino/Filme/
an diese Info, aber auf der Scheibe kann ich dann mit den ausgegebenen inode-Nummern 1410, 1412 usw. nichts anfangen. Da ich keinen Diskmonitor habe, las ich einfach einen Schwung Sektoren per

Code: Alles auswählen

dd if=/dev/sr0 of=/home/domino/temp3.raw bs=2K skip=0 count=1024
auf die Platte ein und konnte dann mittels GHex (einem Datei-Hexmonitor) nachsehen. Ab Position 1410*32→$b040 gibt’s zwar die zweite Auflistung des Inhaltsverzeichnisses der DVD (in vermutlich UTF-16, die erste ist in ASCII und für ISO9660) und darin finde ich auch meine gewünschte Info als Sektornummer (sogar in Little Endian und Big Endian!), aber die Datenstrukturen passen in der Länge nicht zu den inodes 1412, 1415 usw.. Übrigens stimmen diese Nummern nur für Daten-DVDs. Bei VideoDVDs (mit den bekannten Verzeichnissen AUDIO_TS und VIDEO_TS) erhalte ich inodes ab 266, die Daten auf der Scheibe sind aber ab ungefähr $80000 zu finden. Also: inodes sind eine Sackgasse.

Muß ich denn wirklich ein ISO-Dateisystem in mein Progrämmchen einbauen, nur um die Startposition einer Datei auf der Scheibe zu erhalten? Stichwort: Kanonen und Spatzen.

Weiteres Verständnisproblem: Wenn ich nicht dateiweise, sondern partitionsweise lesen will (unter GNU/Linux ist alles eine Datei), komme ich mit

Code: Alles auswählen

Datei = ReadFile(#PB_Any, "/media/domino/Filme/")
nicht weiter. Geöffnet wird zwar, aber die Dateilänge beträgt nur 20 Bytes! Will ich diese mit ReadData() auslesen, werden 0 Bytes zurückgegeben. Mit /dev/sr0 hab ich es noch nicht probiert, da es sich nur um eine 0-Byte-Datei handelt. Weiß da jemand, wo’s bei mir klemmt?

Da muß man Stunden und Tage verdaddeln, nur um an Infos zu kommen, die man gleich mit einer Funktion FileStat() erhalten können sollte. Klar hat man normalerweise mit Festplatten zu tun, auf denen immer mit Datenfragmentierung zu rechnen ist und man deshalb nie von einer linearen Anordnung der Sektoren ausgehen darf. Da ist die Angabe der Sektornummer des ersten Datenblocks sinnbefreit. Da dem Brennen von CDs, DVDs und BDs aber immer die vollständige Erstellung eines Abbildes vorausgeht, kann und wird man immer dafür sorgen, daß es keine Fragmentierung gibt. Hier ist die Angabe des ersten Datenblocks sehr wohl sinnvoll!

Per FileStat() sollten Startposition, Länge in Bytes und in Sektoren, die Sektorgröße, Erstellungs-, Änderungs- und Zugriffsdatum usw. zurückgegeben werden. Für letztere Angaben gibt es die Funktion GetFileDate(), aber für die für mich wichtigen Daten eben keine.

@GPI: Null Problemo! Startsektor der Datei auf der Scheibe mal Sektorgröße plus Absolutposition in Datei gleich Position auf der Scheibe. Mit der Info des Maximalvolumens in Bytes (z.B. 4483MB) und des Innen- und Außendurchmessers des beschreibbaren Bereichs komme ich schnell zum Radius. Der Winkel der Drehachse ist völlig unerheblich. Dann suche ich mir die verkratzte Stelle mit diesem Radius heraus und poliere, bis ich die Stelle lesen kann. Abschließend, wenn alle Daten lesbar sind, wird die ganze Scheibe nochmals auf Hochglanz gebracht oder von den gesicherten Daten gleich eine neue Scheibe gebrannt.

Gruß – Domino
Centrino 2x2GHz, GeForce Graka, mehrere Linux Mint u.a. mit Mate, Linux 3.16
Antworten