erweiterte lokale cddb Abfrage


#1

Hi Florian,

ich habe da mal ne Frage bzgl lokaler Datenbank.
Ich habe immer die aktuelle freedb db auf Platte gespiegelt.
Ich habe viele Alben auf Platte zu denen mir tracknumbers, titles oder beides fehlen.
Ist es nicht moeglich eine lokale Abfrage einzubauen ohne die freedb id zu kennen?
Also ich meine dass mp3tag sich aus den mp3s automatisch die cd infrmationen errechnet wie so ein cddbmp3 tool.
Damit wäre es dann sehr schnell moeglich schlecht benannte Alben schnell zu korrigieren bzw dem eigenen rename stil anzupassen.
Das manuelle raussuchen der freedb id ist echt muehsam und braucht bei vielen Alben unglaublich viel Zeit.

Ich kann leider ueberhaupt nicht beurteilen wieviel Programmieraufwand sowas wäre...

:slight_smile:


Lokale freedb-Abfrage mit JMBase
Offline freedb
#2

Schön wäre dieses Feature schon, allerdings ist es mir im Moment wirklich zuviel Aufwand, da man erstmal eine Hashfunktion und eine Funktion zum Erstellen einer Hashtabelle über der Datenbank erstellen müsste ... und noc ein paar andere Dinge.

Was mich allerdings wirklich freuen würde, wenn jemand mal ein kleines Tool schreiben könnte, das die lokale freedb nach einem Suchtext durchsucht und die freedb-IDs zu der Anfrage liefert. Die Suche würde zwar etwas dauern, aber dieses Tool könnte man dann aus Mp3tag einfach über Optionen, Tools verwenden.

Vielleicht hat ja jemand Lust :slight_smile:

Viele Grüße,
~ Florian


#3

hehe jo das wär gut.
Oder cddb<->mysql, dann koennte man per php suchen. Fänd ich viel schicker. :slight_smile:

Vor allem koennte man dann schnell ne lokal Datenbank durchsuchen...wenn man mal Jahreszahlen zu Alben raussucehn moechte zum Beispiel. Ist auch sehr nuetzlich wenn man keine adequate Internetverbindung hat.


#4

Also ich verfolge die Situation mit der lokalen freedb schon eine ganze Weile und habe mich jetzt entschieden, aktiv zu werden. Da ich hier in Dresden noch kein DSL bekommen kann, muss ich mit ISDN ins Netz - und ich möchte fürs taggen nicht ständig online sein, denn es kostet jede Minute... als armer Student kann man sich das nicht leisten :slight_smile:
Ich hab noch eine Prüfung vor mir und muss renovieren, aber ich fange am Wochenende direkt damit an!

Sinnvoll wäre es wohl, zunächst eine eigene DB zu generieren, die aus der DiscID, dem Interpret, und dem Albumtitel besteht (oder frei wählbar) und die man dann durchsuchen kann (evtl mit Mysql&PHP, damit kenne ich mich zwar aus, ist aber für Windowsnutzer ungünstig). Bei einem Update der lokalen freedb müsste natürlich auch diese DB aktualisiert werden.
Cool wäre es, wenn man in Mp3tag bei "freedb-lokal" eine Auswahl hätte "Disc-Id, berechnen von Programm X", aber bis es soweit ist...
Ersteinmal schreib ich ein effizientes Suchprogramm, was die DiscId ausgibt, das würde für den Anfang schon mal reichen.

Ich warte auf weiteren Input und Vorschläge :slight_smile:

Edit: sorry hatte ganz überlesen dass es dir um cddb geht... aber da das nicht kostenlos ist, sollte man sich bei lokalen dbs schon auf freedb konzentrieren.


#5

Hallo armani,

freut mich, das sich jemand aus Dresden hier ins Forum verirrt hat! Dein Vorschlag klingt super! Über ein solches Tool, würden sich sicher viele freuen.

Was man denke ich berücksichtigen sollte, ist das bei vielen Windows-Nutzern die noch kein Dateisystem unter NTFS haben, nur die lokale freedb im Windows-Format in Frage kommt. Das Tool müsste dann also auch auf jeden Fall die Dateien von der Windows-freedb lesen können.

Du kannst davon ausgehen, dass Mp3tag nie die CDDB unterstützen wird, sondern immer auf die freedb zugreifen wird :slight_smile:

Viele Grüße,
~ Florian


#6

Hatte heut Nachmittag mal einen kleinen Test gestartet und es dauert ohne Optimierung schon eine ganze Weile bis die lokale freedb (win) durchsucht ist, sind ja immerhin auch über 1GB entpackt.
Kannst du vielleicht mal kurz schildern, wie der freedb-Server die DB hasht und wie er auf die passende DiscID kommt? Bzw. mir ein Link geben, wo ich was dazu nachlesen kann?
Wenn man ohne extra Datenbank arbeiten möchte (und das ist glaub ich sinnvoller), kommt man ja quasi nicht um Hashtables rum - andernfalls sitzt man bei jedem Album Minuten vorm Bildschirm.


#7

Hallo Armani,

ich habe eben mal in den Quellcode zum freedb-Server geschaut und anscheinend bauen sich die eine Datei, in der die Alben nach Trackanzahl und dann nach Länge sortiert abgelegt sind. Am Ende der Datei stehen dann die Offsets zu den ersten Alben der jeweiligen Trackanzahl-Gruppe. Die maximale Anzahl von Tracks auf einer CD ist laut Standard 99. Eine Textsuche ist so natürlich nicht möglich.

Das Erstellen einer solchen Hashdatei dauert sicher auch seine Zeit, aber Anfragen an diese Dateie sind dann in wesentlich schnellerer Zeit beantwortet.

Du kannst ja mal in den Quellcode der Server-Software schauen.

Viele Grüße,
~ Florian


#8

Also die Rennovierung hat mich doch mehr Zeit gekostet als eigentlich geplant, das Programm erstellt bis jetzt eine Liste mit allen DISCID- und zugehörigen DTITLE-Einträgen. Es geht nun daran, die DTITLE-Spalte schnellstmöglich nach beliebigen Suchpattern zu durchforsten und natürlich das ganze zu beschleunigen. Ich denke Multithreading ist hier das richtige Stichwort. Für jeden Subordner der Windows-Distribution von FreeDB ein Thread würde schon reichen, um die Erzeugung der Liste deutlich zu verkürzen.

Könntet ihr mal posten, wie die Linux-Distro von FreeDB aufgebaut ist und als Bsp. wie ein File aufgebaut ist?

merci
armani


#9

Hallo Florian!
Ich hab mich heute eingehend mit dem Algorithmus für die DiscID-Erzeugung auseinandergesetzt und bis jetzt zu keinem guten Ergebnis gekommen. Ich habe erst gedacht, es müsste doch möglich sein, auch aus den MP3s eines Albums die korrekte DiscID erzeugen zu können, aber ohne Erfolg.

Ich hätte in dieser Richtung aber mal eine Frage an dich. Bei der Funktion "auf Basis der ausgewählten Dateien ermitteln" musst du doch auch eine Discid erzeugen, die dann mit Hilfe des Fuzzy-Search des Freedb-Servers die korrekte oder annähernd korrekte ID bzw. die Ergebnisse ausspuckt.
Wie erzeugst du denn deine ID?
Ich habe zu Testzwecken einfach mal selbst die Offsets berechnet, indem ich Minuten und Sekunden der einzelnen MP3s genommen hab und jeweils noch 2 Sekunden Pause eingefügt. Der Algorithmus an sich verwendet ja die Frames aus der TOC nicht, aber zur Berechnung der Offsets sind die ja schon von Bedeutung.

Ich würde mittlerweile eher in die Richtung tendieren, Fuzzy-Search lokal zu machen, anstatt die gesamte FreeDB bei jeder Anfrage zu durchsuchen.
Vielleicht könntest du mir den Codeschnipsel zur ID-Erzeugung per Mail schicken?

Grüße
Georg


#10

Hallo Georg,

wichtig ist, dass Du bei den Offsets in Frames rechnest (1 Sekunde = 75 Frames). Pause musst Du nur vor dem ersten Track einfügen (150 Frames).

Allerdings musst Du, wenn Du eine Hashtabelle für eine lokale freedb entwickelst, keine DiscIDs oder Offsets berechnen, sondern die vorhandene Information aus der freedb in Deine Hashtabelle packen. Schau Dir doch mal die freedb Server-Software an. Dort wurde das schon mal gemacht.

Viele Grüße,
~ Florian


#11

JA schon, aber wie bekommst du aus den MP3s die korrekte Framezahl heraus? ich habe es geschafft, eine discid zu erzeugen, die nur um eine Ziffer differiert (eine 8 statt eine 9), es liegt also an einer Sekunde.
Zu Testzwecken habe ich eine AudioCD in MP3 umgewandelt und nebenbei ein fertiges discid-programm von freedb.org benutzt. und ich komme einfach nicht auf die dort angegebenen Framewerte.
Dein Programm benutzt doch auch die id3lib - wie errechnest du damit die korrekten Offsets?

Ich hab die Frames folgendermaßen berechnet:
Magic-Nr = Samplerate (44100) / MP3-Samplegröße (1152) = 38,28125
Frames die Winamp auspuckt / Magic-Nr = Länge in secs mit Nachkommastellen
Frames = Nachkommastellen * 75

Von der MP3 meiner Beispielcd komme ich aber partout nicht auf den Frameoffset, den der "DiscID Calculator" ausspuckt!

Kannst du mir in dieser Hinsicht helfen?

Grüße
Georg


#12

Hallo Georg,

deshalb gibt es ja auch auf Serverseite die Hashtabelle, die geringe Abweichungen handhaben kann und ähnliche Ergebnisse finden lässt. Die errechnete DiscID muss dann nicht 100%ig mit der tatsächlichen überein stimmen, sondern kann auch geringe Abweichungen aufweisen.

Für die Offsets berechne ich einfach "Länge der Datei in Sekunden * 75" und addiere die dann sukzessive und benutze für die Berechnung der Länge nicht die id3lib, sondern eigenen Code.

Viele Grüße,
~ Florian


#13

Du könntest zuerst schauen, ob die MP3 Datei einen Xing / Info / VBRI Header enthält. Dort ist die Frameanzahl schon definiert.

Hier ist die offizielle Xing SDK: http://docs.real.com/docs/xingtech/vbrheadersdk.zip
Und hier die offizielle VBRI SDK: http://www.iis.fraunhofer.de/amm/download/mp3_vbr_sdk.zip

Der Info Header Aufbau ist mit dem des Xing Headers identisch - der einzige Unterschied ist der Identifier "Info" anstelle von "Xing". Übrigens, LAME und GOGO sind die einzigen Encoder, die einen Info Header bei CBR Files schreiben.

Für das Berechnen der Frames bei CBR Dateien ohne Info Header verwende ich folgende Formel (Pseudocode):

Frame Number = Audio Size / (Coefficient * Bit Rate * 1000 / Sampling Rate + Padding)

Audio Size ist die Größe der Audiodaten (ohne ID3 / APE / Lyrics3... Tags) in Bytes.
Coefficient ist abhängig von MPEG Version und MPEG Layer. Hier ist eine Tabelle:

Bit Rate ist der Bit Rate Wert in kbps.
Sampling Rate ist der Sampling Rate Wert in Hz.
Padding ist der Padding Slot Wert. Wenn die MPEG Datei den Padding Bit gesetzt hat hat er den Wert 1 bei Layer 2 und Layer 3, und den Wert 4 bei Layer 1. Wenn der Padding Bit nicht gesetzt ist, ist der Padding Wert 0.

Die Länge der MPEG Datei kann dann wiefolgt berechnet werden (Pseudocode):

Duration = Frame Number * Sample Size / Sampling Rate

Duration (in Sekunden), Frame Number und Sampling Rate (Hz) ist glaube ich klar. Sample Size hat folgende Werte:

Gruß
Sebastian Mares

Edit: Layer 1 Werte für Coefficient und Sample Size gefixt.


Track length sometimes incorrect
#14

Nachdem die Entwicklung dieses Tools wohl nun doch wieder eingeschlafen ist, habe ich im aktuellen Development Build eine Möglichkeit eingebaut, die lokale freedb nach Interpret und Albumtitel zu durchsuchen.

Das Ganze läuft über eine interne Index-Datenbank, die natürlich erst erstellt werden muss (das sollte zumindest bei der freedb im Windows-Format nicht länger als eine halbe Stunde dauern - kommt natürlich auch auf den Rechner an :wink:).

Viel Spaß damit und viele Grüße,
~ Florian


#15

Hi,

scheint ja prima zu funktionieren.

Nun hab' ich aber noch eine Frage. Was passiert, wenn man ein Update über die
lokale Freedb laufen lässt ? Mp3tag scheint das nicht automatisch zu erkennen.
Eigentlich müsste ja dann die Index Datenbank neu erstellt werden. Kann man
sowas vielleicht manuell anstossen? Evtl. durch löschen der vorhandenen Index-
Datenbank ?

Gruß, und weiter so !

Michi


#16

Hallo Michi,

ja, bisher gibt es keine Möglichkeit aus dem Programm heraus ein Update der Index-Datenbank anzustoßen.

Im Moment kannst das Neuerstellen aber durch das Löschen der Datei für die Index-Datenbank Mp3tagFreedb.db erzwingen, die unter
C:\Dokumente und Einstellungen<Benutzername>\Anwendungsdaten\Mp3tag</i>
zu finden ist.

Viele Grüße,
~ Florian