Dateien einlesen sehr langsam

[LadyPreis]

Hallo zusammen

Wir haben in der Berufsschule momentan ein Miniprojekt zur Vorbereitung auf die Abschlussprüfung am Laufen. Ich habe dabei das Thema abbekommen, ID3v2-Tags aus MP3-Dateien auszulesen und diese über eine GUI zu ändern. Dabei ist ein Tag immer so aufgebaut, dass ein 4stelliger String als Header dient, z.B. "TPE1" für den Interpreten. Nach dem Header folgt dann der entsprechende Content.

Das Auslesen funktioniert auch generell, leider nicht sehr performant,d.h. dass bei einer Datei von ca 4MB das Suchen der Tags ca 2 Minuten in Anspruch nimmt.

Momentan läuft die Suche der Tags nach folgendem Schema ab:

Ich lese mit einem RandomAccessFile-Objekt 4 Bytes der Datei ein, wandel die gelesenen Bytes in einen String und vergleiche diesen mit einer Liste aller einzulesenden Tags. Wurde ein Tag gefunden, wird der nachfolgende Inhalt in das entsprechende Attribut der Klasse geschrieben. Wurde kein Tag gefunden, setze ich den Dateizeiger um 3 Positionen zurück und lese erneut 4 Bytes ein.

Dies ist auch der Grund, warum die Suche eine längere Zeit in Anspruch nimmt. Hat jemand von euch vielleicht eine Idee, wie die Suche nach den Tags etwas zügiger durchgeführt werden könnte?

Gruß

Die Lady

[kingofbrain]

Ich verstehe nicht, warum Du bei einer initial nicht erfolgreichen Suche den Zeiger in der Datei um 3 Byte zurücksetzt und wieder 4 Byte liest. Wenn Du keinen Treffer hast, dann sollte doch ein neuer Interpret da sein, den Du Dir für den Vergleich merken musst.

Ansonsten kann man zur Performance erst etwas sagen, wenn man Deinen Quellcode sieht. Davor ist alles Spekulation.

Peter

[VaNaTiC]

@kingofbrain:

Das war nicht korrekt gesagt, sie setzt den Dateizeiger wenn nix gefunden wurde 3 zeichen zurück und liest neu.

@LadyPreis:

Prinzipiell ist das erst der Anfang.

1) Dateizeiger vor und zurücksetzen ist echt heftig.

2) Man arbeitet bei sowas immer mit Peek() zum Prüfen anstatt Read() und danach erst tatsächliches Lesen mit Read().

3) Viel wichtiger ist aber mit Peek() und Read() garnicht erst ein Problem zu bekommen, sondern stattdessen gleich x-Bytes in einen Puffer einzulesen, das hat auch den Vorteil, dass man Blöcke Lesen kann (viel performanter).

4) Schau Dir das MP3-Dateiformat nochmal genau an oder schieb mir mal einen Link rüber, denn ich glaube nicht, dass Tags wahllos in der ganzen Datei vorkommen können. D.h. es gibt sicherlich Vorbedingungen (Header), wo man gezielt drin suchen kann.

5) Und bei 4) wirst Du feststellen, dass es soweit ich weiss unterschiedliche Versionen v1 bis v3 gibt. Musst Du die auch behandeln?

Bearbeitet 23. Februar 2009 von VaNaTiC

[ksg9-sebastian]

Wie Vanatic schon geschrieben hat:

Lies dir mal die Spezifkation zu dem ID3Tag in der entsprechenden Version durch.

Die Tags werden meistens an einer gewissen Stelle in der Datei abgelegt. Bei einer Version steht der ID3-Tag immer in den letzten 128Bytes.

Die ganze Datei zu durchsuchen ist nicht gut.

[speedi]

Leg dir doch nen Byte [] an in das du den Inhalt der Datei speicherst. Da drin kannst deine Operationen dann wesentlich schneller durchführen als wenn du immer auf der Platte rumspringst.

[ksg9-sebastian]

Na ja, dann werden halt unzähliche Megabyte in den Speicher geladen. Das ist zwar etwas schneller, allerdings auch weit entfernt von performat bei mehreren Dateien...

[kingofbrain]

@kingofbrain:

Das war nicht korrekt gesagt, sie setzt den Dateizeiger wenn nix gefunden wurde 3 zeichen zurück und liest neu.

Und genau den Grund für dieses Springen wollte ich ja wissen. Wenn es so ist, wie ksg9-sebastian gesagt hat, und sie in der kompletten Datei quasi byteweise nach Tags sucht, dann macht das natürlich einen Sinn. Ich habe genau diese Funktionalität in meiner Ausbildung auch codiert, und damals (2003) war die MP3-Spezifikation so, dass ab einer bestimmten Stelle in der Datei die Tags abgelegt waren. Man musste also nur diese Stelle finden und alles danach (vermutlich bis zu einem bestimmten Endpunkt) auslesen und interpretieren. So ähnlich wird es immer noch sein.

Peter

[ksg9-sebastian]

ID3v1

http://de.wikipedia.org/wiki/ID3-Tag#ID3v1" data-cite="\"

http://de.wikipedia.org/wiki/ID3-Tag#ID3v1

">

Mit einer Wahrscheinlichkeit von 1:224 ≈ 0,000006 % beginnt ein normaler Datenblock in einem MP3-Datenstrom mit den drei Bytes „TAG“ und würde somit fälschlich als ID3v1-Block identifiziert. Eine mehr oder weniger sichere Lösung für dieses Identifikationsproblem besteht beispielsweise darin, die MP3 Datei nicht von vorne zu durchsuchen, sondern vom Dateiende her, indem man 128 Bytes rückwärts springt und dort wieder vorwärtslesend die „TAG“-Marke sucht. Eine 100%ige Sicherheit gibt es aber auch hierfür nicht. Der Zeichensatz für die Textfelder ist nicht spezifiziert. Üblich sind ASCII, ISO 8859-1 und Unicode im UTF-8-Format. Dadurch kann es auch hier zu Fehlinterpretationen bei Umlauten und Sonderzeichen kommen.

Das Genre des Titels wird als 1 Byte kodiert. Es existiert eine Liste, die angibt, welcher Wert welchem Genre entspricht.

ID3v1

http://de.wikipedia.org/wiki/ID3-Tag#ID3v1.1" data-cite="\"

http://de.wikipedia.org/wiki/ID3-Tag#ID3v1

.1">

Eine Weiterentwicklung des ID3v1-Standards gestaltete sich schwierig, da die vorhandenen Felder bereits starr vorgegeben waren. Allerdings gelang Michael Mutschler eine Erweiterung zu ID3v1.1. Hierfür wurde das Kommentarfeld von 30 auf 28 Byte gekürzt. Darauf folgt ein Byte, das 0 als Belegung enthält. Damit wird sichergestellt, dass alle ID3-Reader mit der Auswertung der Zeichenketten aufhören. Das freigewordene Byte an Position 126 bekam die Bedeutung Titelnummer.

ID3v2

http://de.wikipedia.org/wiki/ID3-Tag#ID3v2" data-cite="\"

http://de.wikipedia.org/wiki/ID3-Tag#ID3v2

">

Obwohl ID3v1 ein großer Erfolg war, weist das Format zahlreiche Schwächen auf, u. A.:

* Eine Begrenzung der Länge der Datenfelder auf weniger als 30 Zeichen, was insbesondere bei Titel und Album eine starke Einschränkung darstellt,

* fehlende Aussage über die Zeichenkodierung des Texts,

* keine Möglichkeit, ID3-Tags zu streamen, da die Kennung am Ende der Datei liegt, die ID3-Datenstruktur mithin an (seekbare) Dateien gebunden ist, aber nicht in Datenströme eingeflochten werden kann und

* zu wenige Metadatenfelder

Deshalb wurde 1998 von Martin Nilsson und anderen ein neues Format entworfen, das den Namen ID3v2 erhielt. Die Zusatzinformationen werden dabei in einem Block vor oder seit ID3v2.4 möglich auch nach den Audiodaten (dem MPEG-Stream) in die Datei eingefügt. Den Beginn eines ID3-Blockes erkennt man am Header (Version ID3v2):

Identifizierung "ID3" Version $04 00 (Major Release, dann Minor Release).

Aktuell (Stand: September 2004) ist die Version 4.0 vom 1. November 2000, auch als ID3v2.4.0 bekannt.

ID3v2-Tags können so kodiert werden, dass Player, die ID3v2 nicht verstehen, diese Tags überspringen und nicht versuchen, sie als Audiodaten zu interpretieren.

u.s.w.

...einfach nachlesen..es gibt sogar genügend Beispielimplementierungen in Java...