Geschwindigkeit bei der Suche nach Musik-Doubletten erhöhen

[goldkante]

Einen schönen guten Tag!

Ich möchte meine Musiksammlung durchsuchen. Hierzu wähle ich als Vergleichskriterium Dateiinhalt und bei Dateiinhalt wähle ich ID3-Tags und Metadaten entfernen aus.

Nun bin ich mir nicht sicher, ob ich als Vergleichsmethode
Byte für Byte
oder lieber
MD5 / SHA
auswählen soll.

Wenn die Sammlung knapp 500GB groß ist, bei ca. 75.000 Dateien,
was wäre hier die "schnellste" Methode um die Doubletten angezeigt zu bekommen?

Zusatzfrage: ist es beim Musik-Vergleich wichtig/nötig, Vergleich zuerst einen Datenblock am Ende auszuwählen?

Ich zähle hier auf Erfahrung, denn das Lesen der Hilfe oder einiger Posts hier konnte mir keine Entscheidungshilfe geben.

Einen schönen Tag noch!

[Anselm]

erwartest Du denn viel Duplikate?

Nur aus Interesse, wie ist denn die Platte angeschlossen? USB2, USB3, SATA?

[Anselm]

Einen schönen guten Tag!

Ich möchte meine Musiksammlung durchsuchen. Hierzu wähle ich als Vergleichskriterium Dateiinhalt und bei Dateiinhalt wähle ich ID3-Tags und Metadaten entfernen aus.

Nun bin ich mir nicht sicher, ob ich als Vergleichsmethode
Byte für Byte
oder lieber
MD5 / SHA
auswählen soll.

Ich habe gerade noch Deinen Beitrag
" Bug? M4A sorgen für Verwirrung bei der Suche "
gesehen.

Ich vermute bei 98% Ähnlichkeit bekommt man mögliche Datenübertragungsfehler raus. Falls Du "wirkliche" Ähnlichkeiten herausfinden willst, ist vielleicht eher das Tool Similarity geeignet:
Similarity - Remove similar, duplicate MP3, music, audio files by content, tags. Check your music collection quality, remove unquality music. Organize your music collection.
http://www.similarityapp.com/

Einen schönen guten Tag!
Wenn die Sammlung knapp 500GB groß ist, bei ca. 75.000 Dateien,
was wäre hier die "schnellste" Methode um die Doubletten angezeigt zu bekommen?

Mit steigender Anzahl von Dubletten wird die "byte für byte" Methode immer schlechter werden.
Einfach ausprobieren, mit einem schnellen Rechner und schneller Platte sollte es keine Stunde brauchen.

[goldkante]

erwartest Du denn viel Duplikate?

Tja, das weiss man ja nie vorher ;-) Doch von 30%-50% Duplikaten gehe ich generell aus. (Eben auch solche Dinge wie: 3x das gleiche Musikalbum gekauft, alldings mit 2 verschiedenen Accounts bei iTunes und einem Account bei Beatport.)

Nur aus Interesse, wie ist denn die Platte angeschlossen? USB2, USB3, SATA?

Einige Platten sind intern verbaut SATA und SSD. Auf dem Rechner, auf dem auch AllDup läuft.

Dann liegen aber noch viele, bzw. die meisten Daten auf einem NAS (intern auch SATA).

Um geziehlt Daten zu prüfen, kann man sich einzelne Verzeichnisse vom NAS lokal auf eine SSD speichern und später wieder "zurücksyncen", ob ich aber mal den obersten Ordner des NAS nach AllDup ziehe, weiss ich noch nicht :-)

Falls Du "wirkliche" Ähnlichkeiten herausfinden willst, ist vielleicht eher das Tool Similarity geeignet

Danke, guter Tipp! Ich habe in den letzten Jahrzehnten einige Programme angetestet, die dieserart Vergleiche zulassen, doch dieses ist mir noch nicht aufgefallen. Super!
In den goldenen 90ern benutzte ich Unique Filer, das funktioniert heutzutage noch, hat jedoch auch noch den "Charme" einer Software, die unter Win95 gelaufen ist :-)

[Anselm]

Bei so vielen Duplikaten würde ich Prüfsummen nehmen.

Die Sachen vom NAS rüberzuziehen lohnt sich nur, wenn Du so einige unterschiedliche Läufe starten willst.

Nebenbei, wenn die Musik mit unterschiedlichen Verfahren kodiert ist (z.B. mp3 und wma) wird Dir Alldup nicht weiterhelfen, wenn Du da etwas anderes herausfindest gib bitte Bescheid. Auch innerhalb von dem selben Musikstück kann die Endung gleich sein, aber der angewandte Algorithmus anders. Wenn ich z.B. ein Stück mit mp3 kodiere und mit durchschnittlicher Bitrate von 192 bit/s und mit 224bit/s kodiere werden die unter Alldup nicht gleich sein. Da musst Du dann auf andere Tools zurückgreifen.

[goldkante]

Bei so vielen Duplikaten würde ich Prüfsummen nehmen.

Ok, danke. Die Prüfsummen kann man aber leider nicht speichern um z.B. nicht wieder alles neu einlesen zu müssen, oder? Soweit ich das im Kopf habe wird bei jedem Durchgang eine neue Prüfsumme generiert anstatt auf eine vorhandene zuzugreifen.

Die Sachen vom NAS rüberzuziehen lohnt sich nur, wenn Du so einige unterschiedliche Läufe starten willst.

Ich denke auch, verschiedene Szenarien antesten und dann im Vortest AllDup einfach mal eine Woche lang auf dem NAS laufen lassen und gucken, was es so alles auftut.
Schade, das man Suchvorgänge nur Abbrechen, nicht aber wiederaufnehmen kann.

Nebenbei, wenn die Musik mit unterschiedlichen Verfahren kodiert ist (z.B. mp3 und wma) wird Dir Alldup nicht weiterhelfen, wenn Du da etwas anderes herausfindest gib bitte Bescheid. Auch innerhalb von dem selben Musikstück kann die Endung gleich sein, aber der angewandte Algorithmus anders. Wenn ich z.B. ein Stück mit mp3 kodiere und mit durchschnittlicher Bitrate von 192 bit/s und mit 224bit/s kodiere werden die unter Alldup nicht gleich sein. Da musst Du dann auf andere Tools zurückgreifen.

Man wird bei Audio nicht um das Hören herumkommen, schliesslich gibt es auch unterschiedliche Versionen eines Liedes, z.B. eine Zensierte-, eine Radio- oder eine Street-Version und/oder einfach noch ein schlechter Rap im Mittelteil. Mal gesungen von diesem oder jenem, aber mit identischer Instrumentierung. Das ist ein spannendes Thema und wird einiges an Zeit in Anspruch nehmen. Nur gut, das es dabei um Musik geht und nicht um dröge Texte.

[Ein Anwender]

Auch wenn das Thema schon ein paar Monate zurückliegt und sich die Angelegenheit vielleicht schon erledigt hat …

Eine weitere Möglichkeit ist ggf. die Verwendung von Mp3Tag.

In dem Programm lässt sich die gesamte MP3-Sammlung in eine Textdatei exportieren mit MD5-Prüfsumme des „nur Audioteils“ dieser Dateien (in Mp3Tag heißt dieser Export „md5audio“). Damit bleiben alle Tags und Sonstiges außen vor. Außer mit MP3s funktioniert das in jedem Fall noch für FLAC-Dateien (möglicherweise auch noch für weitere Formate).

Diese Textliste lässt sich im Nachgang dann weiter auswerten, um besispielsweise Duplikate (anhand der gespeicherten MD5-Prüfsumme) zu finden, wofür ich in solchen Fälle liebend gerne das Befehlszeilenprogramm „awk“ verwende, auch weil es super schnell in der Verarbeitung von Textdateien ist und extrem flexibel dazu.

Ein awk-Einzeiler für eine solche Liste könnte dann so aussehen:

Code: Select all

awk "{if (x[$1]) { x_count[$1]++; print $0; if (x_count[$1] == 1) { print x[$1] } } x[$1] = $0}" mp3tag_exportliste.txt

Damit werden alle Zeilen der Exportliste ausgegeben, deren Prüfsumme gleich ist – also die „rein audioseitig“ identischen Dateien.
Beispielsweise:

Code: Select all

3CE9D345BAD5BE4AADE696C97173066D V:\mp3-unsortiert\2015\Lied_mit_falschem_Namen.mp3
3CE9D345BAD5BE4AADE696C97173066D V:\meine_mp3\Interpret\2004 - Album\02. Song 2.mp3

Vielleicht ist es ja hilfreich für den einen oder anderen.

P. S. Links für die aktuelle Version awk 4.2.1 und eine ältere Version awk 3.1.6 (die es meist genauso tut und als Vorteil sogar, keine Abhängigkeiten zu anderen DLL-Dateien hat, d. h. die eine Datei „awk.exe“ aus der ZIP-Datei reicht).
 

[Administrator]

Das Problem sollte sich mit der neuen Version 4.3 eigentlich erledigt haben, da mit dem neuen Vergleichskriterium 'Ähnliche Musik' jetzt ähnliche Musik mit den folgenden Dateiendungen gefunden werden kann: MP3, FLAC, WMA, WAV, OGG, APE, AAC, MKA, M4A, M4R und MP2.

[Ein Anwender]

Das Problem sollte sich mit der neuen Version 4.3 eigentlich erledigt haben, da mit dem neuen Vergleichskriterium 'Ähnliche Musik' jetzt ähnliche Musik mit den folgenden Dateiendungen gefunden werden kann: MP3, FLAC, WMA, WAV, OGG, APE, AAC, MKA, M4A, M4R und MP2.

Möglicherweise …

Bei einer sehr großen Musiksammlung – dazu würde ich 75.000 Dateien noch nicht mal rechnen - besteht aber das Problem, dass man bei AllDup den gesamten Vorgang für neu hinzugekommene MP3s wiederholen muss.

Beispiel:
Mich besucht ein Freund und bringt mir seine MP3-Sammlung mit. Um nun zu prüfen, ob in seinem Paket Dateien vorhanden sind, die vollständige Duplikate zu meinen Dateien sind, führt meines Wissens kein Weg daran vorbei, dass nun AllDup jede Datei meiner Sammlung mit jeder Datei des Freundes vergleicht, einschließlich Hash-Berechnung. Bei der von mir aufgezeigten Lösung muss nur eine Dateiliste durch MP3Tag für das neue Paket des Freundes erstellt werden und an meine bereits vorhanden Exportliste meiner Sammlung angehängt (auch diese Option bietet Mp3Tag). Anschließend den awk-Befehl über die neue Exportdatei (bestehend aus meinen bisherigen Dateien und den neuen exportierten Dateien des Freundes) laufen lassen, fertig.
Habe ich viele Freunde oder bekomme häufiger Musiksammlungen, kann das ein großer Vorteil sein.

Mit einer einfachen Änderung des awk-Befehl ließen sich genauso gut aber auch zwei getrennte Exportlisten vergleichen. Denkbar wäre sogar, dass der Freund seine Liste exportiert und mir per Mail sendet, so könnte ich diesen Prozess sogar schon im Vorfeld durchführen. Die Dateien müssen gar nicht pysikalisch vorhanden sein, die Export-Hash-Datei(en) ist/sind ausreichend.

Genauso krass ist es übrigens, wenn es nur um eine einzige neu hinzugekommene Datei geht … und ich wissen möchte, ob diese neue Datei bit-identisch (im Audioteil) ist zu einer meiner bisherigen 75.000 MP3s. Hier erkennt man das Problem am besten.

AllDup muss in diesem Fall erst für JEDE meiner 75.000 Dateien den Hash berechnen, um feststellen zu können, ob diese eine - einzig neu hinzugekommene - MP3-Datei mit irgendeiner meiner bisherigen 75.000 Dateien identisch ist. Und das jedes Mal! Ob in einer Stunde, morgen oder übermorgen … AllDup muss es immer wieder und wieder genau so machen … zuerst meine bisherigen 75.000 Dateien hashen.

Bei der MP3Tag/awk-Methode würde dieser Vorgang für eine einzige neue Datei maximal 15 Sekunden dauern (mit MP3Tag starten/Befehlszeile öffnen und allem drum und dran).

Ich möchte damit auch nicht sagen, dass meine vorgeschlagene Methode „das Wunderding“ ist oder gar elegant, aber sie ist sehr, sehr flexibel und - wie bereits gesagt - vermutlich um ein Vielfaches schneller (da allein die Hash-Ermittlung meiner Sammlung jedes Mal entfällt).
 

[goldkante]

Auch wenn das Thema schon ein paar Monate zurückliegt und sich die Angelegenheit vielleicht schon erledigt hat …

Die Angelegenheit hat sich noch nicht erledigt, sondern wächst und gedeiht weiter, wie mein Interesse an neuen Ideen und/oder Tipps. Sei also bedankt für den mp3tag-Tipp und die weiterführung dieses Themas!

(Mp3tag benutze ich ab und an und war mir dieser Möglichkeit gar nicht bewusst. AWK und sonstige CLI Tools kenne ich, benutze ich, versuche sie aber weitestgehenst zu vermeiden, da ich bei diesen Unix Wunderwaffen gerne von Hölzchen auf Stöckchen komme, sprich, ich weiche von der ursprünglichem Problematik ab und sehe mich vor ganz neuen Herausforderungen, die sehr zeitintensiv zu bewerkstelligen sind. Ergo lasse ich die Finger davon, soweit andere Lösungsmöglichkeiten in Aussicht stehen.)

Beispiel:
Mich besucht ein Freund und bringt mir seine MP3-Sammlung mit...

Ich lege dier CloneSpy ans Herz, dies fackelt dein geschildertes Szenario ab. Zur schnellen Überprüfung eine wunderbare Sache.

Ansonsten stimme ich dir (oder meinem vorherigem Post) auch zu, es ist leider sehr unaufregend und macht etwas trübsinnig, AllDup zum wiederholtem Male zuzusehen, wie es die immergleichen Dateien neu durchforstet um Prüfsummen zu erstellen, diese aber nicht als Referenz abspeichern kann.

Das Problem sollte sich mit der neuen Version 4.3 eigentlich erledigt haben

Da es ja ursprünglich um die Geschwindigkeit ging, kann es nicht schaden, das Thema nun umzuschwenken auf die kurz erwähnten angelegten Prüfsummen zur Einsparung von Rechen- und Wartezeit.

Meiner Erfahrung nach ist es -gerade bei vielen, sich wiederholenden oder leicht abweichenden Suchparametern- sehr sinnvoll, weil zeitsparend, auf vorab angelegte Prüfsummen zurückzugreifen zu können und diese zum Vergleich heranzuziehen.

Sicherlich gibt es einiges zu berücksichtgen, denn die gespeicherten Prüfsummen können veraltet sein.
Der Entwickler eines Mitbewerberproduktes beschreibt das sehr gut in seiner Hilfedatei.

Ich zitiere hier ungefragt und schamlos:

Note: Using the database is not safe against damaged files. A file can be damaged if its content changes, but its size and modification time stay the same. If checksums from the database are used to compare two files then, in the worst case, it can happen that the damaged file is retained and the undamaged one is deleted.

Desweiteren gibt es auch noch das Thema der Zugriffszeit auf die gespeicherten Prüfsummen:

Minimum size of stored files refers to the minimum size that a file must have, so that its checksum gets stored into and retrieved from the database. Specifying a limit on the file size is meaningful, because generating the checksum for a small file might be faster than retrieving that checksum from the database.

Ich sehe die Hindernisse für gespeicherte Prüfsummen, allerdings muss es ja nicht immer ein Ausschlusskriterium sein, wenn ein System nicht 100%ig sicher ist (siehe gequotete Beispiele). Es sollte es dem (aufgeklärten) User überlassen werden, für welche Methode er sich in welcher Situation entscheidet (doch es muss ja auch jemand Zeit und Muße in die Programmierung stecken...).

Ich beispielsweise würde (und tue) die gespeicherten Prüfsummen dazu nutzen, schnelle Tests zu machen, welche Suchmethode am geeignetesten für mein Vorhaben ist.
Leider sind meine Ideen/Versuche nicht mal eben mit 5 Test-Dateien zu bewerkstelligen, dazu benötigt es schon 100-1000 Dateien, und ebendiese Anzahl machen die spröde Wartezeit aus, die -theoretisch jedenfalls- durch gespeicherte Prüfsummen um ein vielfaches minimiert werden könnte.

Auch will ich ja nicht immer direkt die gefundenen Duplikate löschen, sondern mir erst einmal einen Überblick verschaffen. Auch hierbei hält die Wartezeit mich eher davon ab und die möglichen Duplikate werden einfach zu den schon vorhandenen Dateien hinzugefügt. (Schneller ist nicht immer besser, doch Zeit ist ein kostbareres Gut als Plattenplatz.)

Seid bedankt!