| Autor |
Beitrag |
rushifell
 
Beiträge: 306
Erhaltene Danke: 14
|
Verfasst: Mi 11.01.12 22:14
Hallo,
Normalerweise benutze ich zum Abspielen von mp3's schon seit Jahren die bass.dll. Da in einer Anwendung die mp3's nur bei Bedarf kurz angespielt werden können, benutzte ich das MCI. Hier der Code zum Abspielen der mp3:
  Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
| Function PlayMp3(const Filename: WideString):Integer;
Var openParms: TMCI_Open_ParmsW;
Begin
FillChar(openParms, SizeOf(TMCI_Open_Parms), 0);
openParms.dwCallback := Form1.Handle;
openParms.lpstrElementName := PWideChar(FileName);
mciID:=0;
Result:=mciSendCommandW(mciID, MCI_OPEN, MCI_OPEN_ELEMENT, Integer(@openParms));
if Result=0 then
BEGIN
mciID := openParms.wDeviceID;
Result:=mciSendCommandW(mciID, MCI_PLAY, MCI_NOTIFY, Integer(@openParms));
END;
End; |
Das funktioniert auch mit den meisten meiner mp3-Dateien. Nun habe ich jedoch eine mp3, bei der sich beim Öffnen der Datei (also beim ersten SendCommand) das Programm aufhängt. Es gibt weder eine Fehlermeldung noch hilft ein Try except end, das Programm muss über den Task-Manager beendet werden. Sobald ich den Id3v2-Tag entferne, lässt sich die Datei normal abspielen. Gibt es eine Möglichkeit, diesen Fehler abzufangen oder zu vermeiden (außer kein MCI zu benutzen  ).
Viele Grüße
|
|
Gausi
Beiträge: 8535
Erhaltene Danke: 473
Windows 7, Windows 10
D7 PE, Delphi XE3 Prof, Delphi 10.3 CE
|
Verfasst: Mi 11.01.12 23:01
Stecken in dem ID3Tag irgendwelche speziellen Dinge drin? Da kann man ja allerhand Schweinkram reinschreiben - auch Zeug, was unter Umständen einen decoder durcheinander bringen kann. Das kann nicht nur bei total bekloppten (rekursiven) Dateien passieren, sondern evtl. auch bei anderen Binärdaten im Tag (z.B. Bilder).
Kann man vielleicht bei MCI einen Offset angeben, sodass die Datei erst ab einer bestimmten Stelle (d.h. nach dem ID3v2Tag) verarbeitet werden soll? Ansonsten würde mich das mp3 (mit ID3-Tag) mal interessieren, wie das so aussieht.
_________________ We are, we were and will not be.
|
|
rushifell 
Beiträge: 306
Erhaltene Danke: 14
|
Verfasst: Mi 11.01.12 23:12
| Gausi hat folgendes geschrieben: | | Stecken in dem ID3Tag irgendwelche speziellen Dinge drin? |
Ist die Datei demo_unicode.mp3 aus Deinen mp3fileutils, also n' Haufen Schweinkram drin Ich benutze die Datei eigentlich nur zum Testen der Unicode-Darstellung.
Dachte auch schon an die Möglichkeit, die Datei temporär zu speichern und den Id3-Tag vor dem Abspielen zu entfernen.
|
|
Gausi
Beiträge: 8535
Erhaltene Danke: 473
Windows 7, Windows 10
D7 PE, Delphi XE3 Prof, Delphi 10.3 CE
|
Verfasst: Mi 11.01.12 23:26
Da steckt zwar bekloppter Text drin, aber das ist nichts, was den Decoder durcheinanderbringen sollte. Evtl. machen die beiden Jpegs dadrin Ärger - aber Bilder im Tag sind jetzt auch nicht so ungewöhnlich.  _________________ We are, we were and will not be.
|
|
rushifell
Beiträge: 306
Erhaltene Danke: 14
|
Verfasst: Do 12.01.12 00:56
Danke, das Problem hat sich erledigt. Ein oder mehrere Frames scheinen nicht kompatibel mit der Version des Id3v2-Tags zu sein. In der Id3Lib, die ich benutze, gibt es eine Möglichkeit, den Id3v2-Tag diesbezüglich zu überprüfen. Um welche Frames es sich handelt, kann ich im Moment nicht sagen. Am Unicode und den Bildern scheint es jedoch nicht zu liegen (die hab ich manuell in andere Id3Tags kopiert und getestet). Ich überprüfe nun vor dem Abspielen der mp3 einfach den Id3v2-Tag auf seine Gültigkeit.
Viele Grüße
P.S. : Ich bin erstaunt, dass das MCI so empfindlich darauf reagiert und den Id3-Tag nicht einfach ignoriert.
|
|
rushifell
Beiträge: 306
Erhaltene Danke: 14
|
Verfasst: Sa 04.02.12 09:56
Es liegt doch nicht an den Tag-Inhalten. Ich habe den kompletten Id3v2-Tag mit Nullen (#0) gefüllt, und das Programm hängt sich beim Öffnen der Datei immer noch auf. Anschließend habe ich den Id3v2-Tag vor eine andere mp3-Datei gesetzt. Das Programm hängt sich wieder auf. Also liegt es definitiv am Tag. Wenn ich die Tag-Version von 04 auf 03 ändere, lässt sich die Datei problemlos öffnen und abspielen. Allerdings kommt MCI mit anderen Dateien mit Tag-Version 04 klar. Die Tag-Größe im Header ist übrigens korrekt angegeben. Wenn die Angabe der Tag-Größe im Header falsch wäre, würde ich das ganze ja noch verstehen. Sehr merkwürdig. Wenn ich keine zufriedenstellende Lösung finde, distanziere ich mich von MCI.
Viele Grüße
|
|
Gausi
Beiträge: 8535
Erhaltene Danke: 473
Windows 7, Windows 10
D7 PE, Delphi XE3 Prof, Delphi 10.3 CE
|
Verfasst: Sa 04.02.12 10:11
Dann würde ich darauf wetten, dass MCI ein Problem damit hat, wenn die Musik zu weit hinten in der Datei anfängt.
Wenn der Tag in Version 2.3 drin ist, erkennt Windows/MCI den Tag und springt entsprechend nach vorne. Wenn lauter Nullen drin sind, kann das nicht passieren. Und weil selbst Windows 7 den ID3Tag in Version 2.4 nicht unterstützt, ist damit wohl auch geklärt, warum das in dem Demofile nicht klappt (da ist der Tag wegen der beiden Bilder relativ groß), in anderen aber schon, wenn der Tag da kleiner ist. _________________ We are, we were and will not be.
Für diesen Beitrag haben gedankt: rushifell
|
|
rushifell
Beiträge: 306
Erhaltene Danke: 14
|
Verfasst: Sa 04.02.12 10:22
| Gausi hat folgendes geschrieben: | | Und weil selbst Windows 7 den ID3Tag in Version 2.4 nicht unterstützt, ist damit wohl auch geklärt, warum das in dem Demofile nicht klappt. |
Danke. Das ist wirklich armselig, gerade weil ja das Offset der Audiodaten im Id3v2-Tag angegeben ist. Dann werde ich doch die Bass.dll nutzten. Alles andere ist zu aufwendig.
|
|
|
