filtern von MP3 nach bitrate

[Gothmoth]

ich suche einen weg um mittels der TC suchfunktion MP3 titel mit einer bestimmten bitrate zu finden.

also = 256 kbits oder z.b. >128 kbits.

geht das vielleicht mit einem plugin?

[milo1012]

Da gibt es sogar mehrere die passen würden.
Da wären in erster Linie MediaInfo (auch gut geeignet für fast alle anderen Mediendateien),
und dann noch wdxtaglib.

Plugin laden und installieren und dann halt bei der TC-Suche im Reiter Plugins das jeweilige Plugin-Feld aktivieren.
Erstelle am besten vorher eine Benutzerdef. Spalte um zu sehen ob die Bitrate auch hinkommt.
MediaInfo könnte bei MP3s etwas auf- oder abrunden.

[Dalai]

Da gibt es einige Plugins: Media, AudioInfo, MediaInfo (milo1012 hat den Download bereits verlinkt), TCMediaInfo (aktuell ist anscheinend 0.7.4), MediaInfoWDX. Die letzten drei bauen allesamt auf MediaInfo auf (wie könnte es anders sein ), allerdings habe ich die Feststellung gemacht, dass sie relativ langsam sind, weil sie viel können. Deshalb halte ich mich an die beiden erstgenannten Plugins, solange ich keinen TC 64 Bit verwende.

MfG Dalai

[Gothmoth]

danke!!

ich habe mal MediaInfoWDX-v0.06.2 ausprobiert allerdings erzielte keine der audio bitraten einstellungen ein ergebnis.

http://i.imgur.com/zUXn9OR.jpg

habe alle möglichen einstellungen (bps, kbps etc) durchprobiert.
habe auch die anderen "eigenschaften" (bitrate_nominal_audio etc.) ausprobiert.

hat auch die mp3´s auf meiner festplatte durchsucht... aber nichts ausgefiltert.

was mache ich falsch?
das plugin scheint ja sehr nützlich zu sein.

ich habe vergessen zu erwähnen, ich nutze TC 64 bit.


werde mir mal die anderen anschauen.



EDIT:

mit wdx_WDXTagLib_1.1.2 klappt es.

falls einer eine idee hat wie es mit dem anderen plugin funktioniert, würde ich das trotzdem gerne erfahren.

danke nochmals!!

[Dalai]

ich habe mal MediaInfoWDX-v0.06.2 ausprobiert allerdings erzielte keine der audio bitraten einstellungen ein ergebnis.

http://i.imgur.com/zUXn9OR.jpg

Da ist aber kein Haken drin, dass TC mit Plugins suchen soll. Hab's grad mal mit MediaInfo ausprobiert, funktioniert wie erwartet:

Code: Select all

mediainfo | audio bitrate | > | 256 | kbps

MfG Dalai

[Gothmoth]

ist aber kein Haken drin, dass TC mit Plugins suchen soll.

ja sorry, das war aber nur auf dem screenshot der fall.

den punkt "audio bitrate" habe ich im mediainfodx plugin auch gar nicht.

http://i.imgur.com/NNVXgIw.jpg


aber wie gesagt, mit dem andern plugin funktioniert es ja.

[Dalai]

Du hast Recht und sogar einen Bug in dem Plugin gefunden. Das Problem liegt daran, dass die dem Plugin beiligende fields.txt einen Fehler oder eher eine Beschränkung in der ersten Zeile enthält:

Code: Select all

89	1L:\;G:\

Die Lösung ist, die fields.txt aus der Plugin-Version 0.0.5 zu benutzen. Alternativ kann man mit einem Editor die Zeichen nach der Zahl 89 entfernen, den nachfolgenden Tab dabei aber stehenlassen!

MfG Dalai

[milo1012]

Ich hatte nicht umsonst nur die beiden Plugins verlinkt.

MediaInfo weil es ist das in meinen Augen einzig saubere ist, schlicht weil es nur die Mediainfo-DLL linkt ohne Geraffel drumherum (C-Runtimes, Sqlite-DLL), außerdem das einzige mit Source.
TCMediaInfo und MediaInfoWDX scheinen mir nicht ganz sauber und stabil, der kleine Fehler in der cfg zeigt es.
(wozu überhaupt die Fields.txt ist mir auch ein Rätsel, die MediaInfo-Felder sind eigentlich relativ übersichtlich,
da muss nichts konfiguriert werden, das Plugin von TBeu zeigt wie es geht).

Wenn es wirklich nur um Audiodateien geht ist wdxtaglib hervorragend geeignet,
vor allem weil es auch MP3s mit kaputten Headern problemlos nimmt (im GGs. zu MediaInfo) und ich die Source auch einigermaßen verifizieren kann.
Außerdem ist es schnell.
Eine 30 GB MP3-Sammlung wurde bei mir in weniger als 15 Sekunden nach Bitraten abgescannt, bei MediaInfo mal locker das doppelte.

Media und AudioInfo sind wirklich nicht mehr zeitgemäß, vor allem haben sie Probleme mit eingebetteten Album-Art-JPGs.

[Dalai]

MediaInfo weil es ist das in meinen Augen einzig saubere ist, schlicht weil es nur die Mediainfo-DLL linkt ohne Geraffel drumherum (C-Runtimes, Sqlite-DLL), außerdem das einzige mit Source.

Das sehe ich anders. Bei MediaInfo ist man auf die Felder beschränkt, die der Autor vorgesehen hat. Ich hab es erst vor ein paar Tagen gemerkt, als ich die im TC 32 Bit genutzten Plugins Media & AudioInfo mit würdigen Nachfolgern/Alternativen im TC 64 Bit ersetzen wollte. MediaInfoWDX läuft erst ab Vista, weil eine bestimmte Funktion im XP-Kernel fehlt, MediaInfo bietet die Felder nicht, die ich brauchte, also blieb nur TCMediaInfo. Dessen Standardkonfiguration in Form einer XML ist sicher nicht unbedingt immer passend, aber mit ein bisschen Einarbeitung gelang es mir dann, die gewünschten Felder (Audio- und Video-Codecs in menschenlesbarer Form) anzeigen zu lassen.

Bzgl. Runtimes & Geraffel kann ich dir auch nur teilweise zustimmen: von MediaInfoWDX gibt es eine statisch gelinkte Version und bei TCMediaInfo kann man die sqlite*.dll löschen, wenn man sie in der XML deaktiviert. Kein Problem also. Davon abgesehen sollte man sich das mit dem Deaktivieren gut überlegen, denn das Cachen bringt durchaus Vorteile, wenn man mit aktivierter benutzerdef. Spaltenansicht durch die Verzeichnisse navigiert; es genügt ja, die SQL DB im RAM erzeugen zu lassen.

[...] (wozu überhaupt die Fields.txt ist mir auch ein Rätsel [...]

Ganz einfach: Je mehr Felder ein Plugin bietet, desto langsamer wird es (und desto unübersichtlicher wird es für den Nutzer). Deshalb sind standardmäßig nur die 89 aktiv, die restlichen können bei Bedarf aktiviert oder deaktiviert werden. Genau aus demselben Grund ist MediaInfo auch auf eine bestimmte Menge Felder begrenzt.

[...] die MediaInfo-Felder sind eigentlich relativ übersichtlich,
da muss nichts konfiguriert werden, das Plugin von TBeu zeigt wie es geht).

Übersichtlich ja, aber wie ich schon sagte: man ist auf den Autor angewiesen und muss dem vertrauen, dass der schon weiß, welche Felder die Nutzer brauchen. Der Punkt ist: "One size fits all" funktioniert nicht wirklich gut (Win8 ist das aktuelle Negativbeispiel dafür). Ja, man könnte sich den Source nehmen und selbst kompilieren, aber sind wir doch ehrlich: das macht keiner, wenn es nicht die dringende Notwendigkeit sowie entsprechende Kenntnisse dafür gibt.

Media und AudioInfo sind wirklich nicht mehr zeitgemäß, vor allem haben sie Probleme mit eingebetteten Album-Art-JPGs.

Da es hier um Bitraten ging, spielt das nur eine untergeordnete Rolle.

MfG Dalai

[milo1012]

Du argumentierst hier mit deinem persönlichen Anwendungszweck.

Bei MediaInfo ist man auf die Felder beschränkt, die der Autor vorgesehen hat...
Übersichtlich ja, aber wie ich schon sagte: man ist auf den Autor angewiesen und muss dem vertrauen, dass der schon weiß, welche Felder die Nutzer brauchen

Jetzt mal ernsthaft, MediaInfo bietet zwar viele Felder, mindestens die Hälfte davon ist in den meisten Mediendateien aber überhaupt nicht verfügbar.
Der Durchschnittsuser wird selten mehr brauchen als Länge, Bitrate, Codec,
vielleicht noch Auflösung und Bildwiederholrate bei Videodateien.
Dinge wie Farbraum, Farbunterabtastung, Encoder- und Container-Version brauchen wirklich nur Experten.
Wenn du nicht gerade modernste MKV- oder MP4-Container hast und diese auch mit Tagger-fähigen Bibliotheken geschrieben wurden sind die besagten Felder sowieso nicht verfügbar.

Es ging hier um allgemeine Anwendungsfälle, wie Bitrate einer ist, da brauchst du nicht sämtliche Felder.

MediaInfoWDX läuft erst ab Vista...von MediaInfoWDX gibt es eine statisch gelinkte Version

Noch ein Punkt warum ich das Plugin meide.
Sorry, aber als Plugin-Autor die statisch gelinkte Version nur optional zu machen ist ein no-go.
Dynamisch linken kann man gerne für ein Standalone-Programm, aber für ein Plugin sollte das vermieden werden.
Ich könnte das jetzt noch weiter ausführen aber das wird Off-Topic.

das Cachen bringt durchaus Vorteile

Nur gut das die meisten Infos im Header oder an spezifischen Stellen der Dateien zu finden sind und deswegen sowieso nur einige kBytes zu verarbeiten sind und mit hoher Wahrscheinlichkeit der Datei-Cache zum tragen kommt.
Mit dem selben Argument könnten wir sämtliche wdx-Plugins mit einem Caching-Algorithmus und DB versehen...und die brauche ich wesentlich öfter als Mediendateien.
Ich habe das Cachen ausprobiert und keinen Unterschied gemerkt.
Aber bitte, wer es braucht soll es nutzen...

Je mehr Felder ein Plugin bietet, desto langsamer wird es

Bitte? Ein wdx-Plugin liefert das was gefordert wurde. Dann ist es egal ob es 200 oder nur fünf verschiedene Felder geben könnte.
Es ist allerhöchstens wichtig beim laden der verfügbaren Felder, aber das spielt sich noch alles unter Konfiguration ab.
Klar, wenn ich sämtliche Felder auf einmal nutzen wollte würde es vermutlich langsamer sein als bei nur ein paar wenigen, aber wer macht das bitte?
Bei Benutzerdefinierten Spalten aus Platzmangel wohl kaum.

Da es hier um Bitraten ging, spielt das nur eine untergeordnete Rolle.

Äh, nein, gerade weil hier die Bitrate falsch berechnet wird, da das Jpg einige kByte "Blinddaten" hinzufügt.

MediaInfo bietet die Felder nicht, die ich brauchte

Die da wären? (nur aus Interesse)

[Dalai]

Du argumentierst hier mit deinem persönlichen Anwendungszweck.

Korrekt. Aber nicht nur. Ich habe dir widersprochen, dass MediaInfo das einzig saubere Plugin der drei verfügbaren wäre, und dargelegt, warum ich das tue.

Der Durchschnittsuser wird selten mehr brauchen als Länge, Bitrate, Codec,
vielleicht noch Auflösung und Bildwiederholrate bei Videodateien.

Richtig, und gerade um die Codecs ging es mir. Was gibt MediaInfo denn Sinnvolles aus für ein AVI mit DivX 5.0 Codec? Nur den FourCC (DX50) und das war's, wenn das Video nicht gerade noch den Video Encoded Library enthält. Für Audio müsste man ja "nur" 3 Felder bemühen, um den einen Codec vollständig zu haben, und als menschenlesbar bezeichne ich den FourCC nicht gerade...

Es ging hier um allgemeine Anwendungsfälle, wie Bitrate einer ist, da brauchst du nicht sämtliche Felder.

Ich habe auch nicht behauptet, man bräuchte alle Felder, nur möchte ich als Nutzer (oder besser gesagt Admin) entscheiden, welche Felder ich haben (und meinen Nutzern verfügbar machen) will.

Sorry, aber als Plugin-Autor die statisch gelinkte Version nur optional zu machen ist ein no-go.

Ein NoGo wäre es, wenn keine statisch gelinkte Version existierte . Aber ich bevorzuge normalerweise auch die statisch gelinkten Versionen (bei FileInfo z.B.).

Ich habe das Cachen ausprobiert und keinen Unterschied gemerkt.

Ich hab es ebenfalls ausprobiert und gerade bei Dateien auf Netzlaufwerken einen extremen Geschwindigkeitsvorteil gehabt.

Da es hier um Bitraten ging, spielt das nur eine untergeordnete Rolle.

Äh, nein, gerade weil hier die Bitrate falsch berechnet wird, da das Jpg einige kByte "Blinddaten" hinzufügt.

Ich hab noch kein Problem oder falsche Bitraten mit den Plugins gehabt, und die MP3s von Amazon enthalten fast alle ein Cover in Form eines JPGs. Oder meintest du etwas anderes?

MediaInfo bietet die Felder nicht, die ich brauchte

Die da wären? (nur aus Interesse)

Audio_Codec_List, Video_Codec_List und Codec_Description (Section Video). Das sind diejenigen Felder, die für meine Bedürfnisse sinnvolle menschenlesbare Infos zu den Codecs enthalten.

Übrigens hat TCMediaInfo noch einen weiteren Vorteil: das Ding lässt sich als Lister-Plugin nutzen und ist mit seiner Anzeige der Infos IMO sehr übersichtlich. Das hat sich als sehr nützlich erwiesen, um die von mir gewünschten Felder zu ermitteln.

Aber streiten sollten wir uns deswegen nicht. Jeder soll das benutzen, was er für richtig/sinnvoll hält. Ich wollte nur einige pauschale Aussagen richtigstellen.

MfG Dalai

[milo1012]

das Ding lässt sich als Lister-Plugin nutzen

Ja, indem ich die neueste Beta-Version mühsam über wincmd.ru suche und die Dateiendung ignoriere wenn ich es als wlx hinzufüge.
Auch mal wieder ein typisches Beispiel für ein Plugin was weder hier noch auf totalcmd.net zu finden ist.
Für mich weitere Argumente es für den Standardnutzer allerhöchstens zu erwähnen aber nicht unbedingt zu empfehlen.

die MP3s von Amazon enthalten fast alle ein Cover in Form eines JPGs

Ich weiß zwar nicht ob wir dann von VBR sprechen, aber gerade da gibt es Probleme.
Ich benutze ein altes EncSpot als Referenz, weil ich weiß dass er jeden Frame sauber scannt.
Ich habe hier einen "Pool" von problematischen MP3s (wohl wegen problembehafteten Frame-Headern) mit relativ großen AlbumArt-JPGs,
und davon macht AudioInfo bei der Bitrate am meisten Probleme.
Bei Media sind es auch noch einige Dateien. Sobald das Bild weg ist ist (fast) alles OK.
Wdxtaglib ist am nächsten dran alles einigermaßen korrekt zu berechnen, auch wenn abgerundet wird.

Ich wollte nur einige pauschale Aussagen richtigstellen.

Es sind Meinungen. Richtigstellen ist wohl das falsche Wort in diesem Kontext. Aber alles gut.

[Dalai]

Ja, indem ich die neueste Beta-Version mühsam über wincmd.ru suche und die Dateiendung ignoriere wenn ich es als wlx hinzufüge.

Naja, so schlimm ist das nicht. Ich gebe zu, dass ich das nur zufällig gesehen habe, als ich die History durchgeschaut habe; eine Beschreibung zur Installation als WLX wäre sicher gut (vielleicht kommt die noch?).

Auch mal wieder ein typisches Beispiel für ein Plugin was weder hier noch auf totalcmd.net zu finden ist.

Tja, wie ich schon in einem anderen Thread schrieb: jeder Autor hat seine eigenen Vorstellungen, wo und wie er Plugins veröffentlicht. Offenbar hat sich der Autor dazu entscheiden, es nur um russischen Forum zu veröffentlichen. Vielleicht kommt es noch auf totalcmd.net, wenn es stabiler ist?

die MP3s von Amazon enthalten fast alle ein Cover in Form eines JPGs

Ich weiß zwar nicht ob wir dann von VBR sprechen, aber gerade da gibt es Probleme.

Ja, die haben (fast) alle VBR.

MfG Dalai