Entwickler-Ecke
Multimedia / Grafik - Inhalt von Mp3-File in String umwandeln
Glostami - Fr 15.10.10 23:07
Titel: Inhalt von Mp3-File in String umwandeln
Hallo!
Meine Frage:
Für mein Programm muss ich den Inhalt einer mp3 Datei in einen String umwandeln.
Meine Idee war es, die Datei in ein TMemo zu laden und dann einfach die Zeichenumbrüche zu entfernen:
Delphi-Quelltext
1: 2: 3: 4: 5: 6:
| var quelle : text; begin
Memo_mp3.Lines.LoadFromFile(OpenDialog1.FileName); quelle := StringReplace(Memo_mp3.Text,SLineBreak,'',[rfReplaceAll]); end; |
Wenn ich das dann ausführe, wir nur folgendes geladen: ID3 (also nut die ersten 4 Zeichen)
Wenn ich das mp3-File aber per Copy&Paste (z. B. über den Editor) einfüge klappt alles wunderbar. :?
Ich hab das ganze schon mit einem RichEdit versucht, dort wurde es auch nicht follsändig geladen. Außerdem kann dieses nur 65536 Zeichen verkraften, für ein mp3-File also zu wenig.
Danke im Vorraus für Antworten
Glostami
jaenicke - Fr 15.10.10 23:25
Wenn du da etwas ersetzt, brauchst du dich nicht wundern, wenn es hinterher nicht mehr das selbe ist. Die Zeichen 13 und 10 können in einer MP3 Datei durchaus oft vorkommen. ;-)
In einen String Laden geht sehr einfach (auch wenn ich nicht verstehe wozu^^):
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13:
| var FileContents: TFileStream; MyString: AnsiString; begin FileContents := TFileStream.Create(..., fmOpenRead or fmShareDenyNone); try SetLength(MyString, FileContents.Size); FileContents.ReadBuffer(PChar(MyString)^, FileContents.Size); finally FileContents.Free(); end;
|
// EDIT: Korrektur wegen UnicodeStrings
Glostami - Fr 15.10.10 23:46
Wow...
Sehr effektive Methode... Klappt wunderbar!
Danke.
Wenn ich aber diesen Text dann in einem TMemory oder in einem Edit ausgeben will, kommt trotzdem nur ID3...
Ansonsten klappt alles :zustimm:
Glostami - Fr 15.10.10 23:49
Gerd Kayser hat folgendes geschrieben : |
Glostami hat folgendes geschrieben : | Für mein Programm muss ich den Inhalt einer mp3 Datei in einen String umwandeln. | Sorry, aber das ist einfach nur Murks. Wenn Du die ID-Tags einer Mp3-Datei auslesen, verändern und schreiben willst, geht das anders. ... |
Stimmt, aber die will ich ja nicht verändern.
Trotzdem Danke
Gerd Kayser - Fr 15.10.10 23:57
Glostami hat folgendes geschrieben : |
Stimmt, aber die will ich ja nicht verändern. |
Auch wenn man das nur auslesen will, packt man die Datei nicht in einen String. Schau in das genannte Beispiel.
jaenicke - Sa 16.10.10 00:08
Glostami hat folgendes geschrieben : |
Wenn ich aber diesen Text dann in einem TMemory oder in einem Edit ausgeben will, kommt trotzdem nur ID3... |
Das ist eben der Inhalt der Datei, was erwartest du denn? :gruebel:
Und sobald ein Nullzeichen dabei ist, ist Schluss mit Anzeige, weil das als Endzeichen eines Strings benutzt wird.
Was willst du denn angezeigt haben?
Delete - Sa 16.10.10 03:10
Was soll das für einen Sinn machen eine nicht Textdatei als Text ausgeben zu wollen? Dass da nur Müll ankommt, ist doch logisch. Was hast du denn erwartet? Den Text? Die Noten? ;) Und wenn du es unbedingt als Text anzeigen willst, dann codiere es vorher so, dass keine Steuerzeichen mehr enthalten sind. Base64 wäre da eine Möglichkeit.
delfiphan - Sa 16.10.10 09:15
Wenn du den Code oben nimmst, machst du implizit eine Annahme über das Format und Codierung des Strings. In älteren Delphi-Versionen ist 1 Byte = 1 Char, aber die Codierung kann unterschiedlich sein (je nach Zeichensatzeinstellung). Bei neueren Versionen ist 1 Char nicht mehr 1 Byte und der Code oben funktioniert nicht mehr.
Ausserdem zeigt PChar() bei einem leeren String nicht auf nil, was zwar beim Code oben nicht tragisch ist, weil nichts geschrieben wird; aber Pointer() wäre meiner Meinung nach korrekter; bzw. den Code würde ich bei einer leeren Datei gar nicht so durchlaufen lassen.
jaenicke - Sa 16.10.10 09:19
Stimmt, ich habe vergessen AnsiString zu nehmen. Ein UnicodeString macht hier ja keinen Sinn, deshalb bringt es nichts, das via SizeOf(Char) zu berechnen und in einen zu legen.
Gausi - Sa 16.10.10 09:19
Ist zwar hier etwas OT, aber das muss dann doch raus: Lesen geht mit der verlinkten Unit, aber verändern und schreiben sollte man die ID3v2Tags damit nicht. Dabei können nämlich eine ganze Reihe von Informationen verloren gehen, und das ist Murks ;-). Besser sind da die ganz unten in dem Topic verlinkte ID3Lib von Muetze1, oder meine
Mp3FileUtils [
http://www.delphi-forum.de/topic_MP3FileUtils_51410.html].
Mich würde aber auch mal der Sinn des Unterfangens hier interssieren. :D
delfiphan - Sa 16.10.10 09:26
jaenicke hat folgendes geschrieben : |
Stimmt, ich habe vergessen AnsiString zu nehmen. Ein UnicodeString macht hier ja keinen Sinn, deshalb bringt es nichts, das via SizeOf(Char) zu berechnen und in einen zu legen. |
Obwohl die Bedeutung eines AnsiStrings wieder abhängig von der Codepage ist. Da könntest du die Daten auch gleich in ein Array of Float laden ;) Es ist daher so oder so nicht sinnvoll. Ab Delphi2009 könntest du korrekterweise RawByteString nehmen.
Gerd Kayser - Sa 16.10.10 11:39
Ich habe einfach den ersten Google-Link als Beispiel genommen. Und da wird schon ersichtlich, wie man an die Informationen dran kommt. Ob man beim Schreiben Infos verliert, sollte schon einem auffallen, wenn man sich mit der Materie ernsthaft beschäftigt. Die Copy-und-Paste-Programmierer dürften da allerdings auf verlorenem Posten stehen. ;-)
Zitat: |
Mich würde aber auch mal der Sinn des Unterfangens hier interssieren. :D |
Ganz einfach: Es gibt KEINEN Sinn, eine binäre Datei in einen String einzulesen. Das kommt dabei raus, wenn man die Grundlagen nicht beherrscht und mit Begriffen wie Header, Records, Dateizugriffen, Dateiaufbau usw. nichts anzufangen weiß.
Teekeks - Sa 16.10.10 14:45
Nur so: WO hat der TE denn behauptet die ID3-Tags zu verändern zu wollen?
Er hat einmal ID3 geschrieben, was daran liegt dass das alles war was er bei seiner Methode raus gefunden hat.
Interessieren würde es mich aber auch was er damit erreichen möchte...
Glostami - So 17.10.10 19:52
Der Sinn des ganzen sollte folgender sein:
Für mein Programm "FileToBMP - Converter" benötoge ich hat nun mal den Inhalt einer Datei. Wenn ich das ganze in einenn String lade, kann ich mit length(s) die größe der Daten heraufinden. Daraus kann ich halt berechnen wie viele Pixel das Bild haben soll. Da Pixel aber ganzzahlig sind, benötige ich manchmal nicht alles von der Datei, ein Paar Zeichen können wegelassen werden, was mit einer Schleife wunderbar funktioniert. Schließlich kann ich noch zur besseren Formatierung der Datei die Absätze bearbeiten, sodass eine Zeile genau soviele Zeichen hat, wie das Bild Pixel. Wenn ich das alles in einem String hab, kann ich die ja schön einfach einfügen.
Trotzdem Danke für die Hilfe.
Ach so, um kommentaren vorzubeugen: Ich weiß, das ich noch einen Header schreiben muss...
jaenicke - So 17.10.10 19:55
Ein String als Datencontainer ist keine gute Idee...
Den Dateiinhalt kannst du z.B. als Stream auslesen mit TFileStream (wie oben schon gezeigt). Und wenn du schnellen Zugriff auf die gesamte Datei brauchst, kannst du einen TMemoryStream mit den Daten füttern oder MMFs benutzen.
In jedem Fall macht das viel mehr Sinn und ist deutlich schneller als mit Strings und den daraus entstehenden Problemen herumzufriemeln.
Delete - So 17.10.10 21:12
Glostami hat folgendes geschrieben : |
Wenn ich das ganze in einenn String lade, kann ich mit length(s) die größe der Daten heraufinden. |
In der Delphipraxis gab es früher mal so einen Experten, der hat Screenshots grundsätzlich immer in einer Word-Datei hochgeladen. :wall:
Wie wäre ein einfacher Aufruf von GetFileSize(Ex), um die Dateigröße zu ermitteln? Oder du lädst die Datei in einen FileStream und rufst dann die Methode Size auf oder du machst es mit FindFirst(File).
delfiphan - Mo 18.10.10 18:10
Glostami hat folgendes geschrieben : |
Der Sinn des ganzen sollte folgender sein |
Dann nimm wenn schon
array of Byte aber besser arbeitest du direkt mit einem Stream.
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!