Help - Search - Members - Calendar
Full Version: Beschränkung bei Dateigröße
Mp3tag Forums > Mp3tag - Deutsch > Allgemein
nikopet
Gibt es bei Mp3tag eine Beschränkung durch die Dateigröße?
Ich habe eine CD mit 192/24 gerippt; die daraus entstehende WAV-Datei hat 2,2 GB. Mp3tag verweigert hier den Dienst - im Gegensatz zum Tagging mit JRiver.
Wenn ich die Datei auf 96/24 reduziere, ist die Datei nur noch 1,1 GB groß und ich kann Mp3tag anwenden. Nach einer erneute Konversion auf 192/24 wiederholt sich das oben beschriebene Problem.
MP3Freak_Peter
QUOTE (nikopet @ Mar 27 2017, 05:48) *
Gibt es bei Mp3tag eine Beschränkung durch die Dateigröße?
Ich habe eine CD mit 192/24 gerippt; die daraus entstehende WAV-Datei hat 2,2 GB. Mp3tag verweigert hier den Dienst - im Gegensatz zum Tagging mit JRiver.
Wenn ich die Datei auf 96/24 reduziere, ist die Datei nur noch 1,1 GB groß und ich kann Mp3tag anwenden. Nach einer erneute Konversion auf 192/24 wiederholt sich das oben beschriebene Problem.


kurze Frage vorab, warum verwendset du WAV und nicht FLAC? ohmy.gif huh.gif
Rippst du SuperAudio CDs?

Zum Problem:
Zum ändern des Tags muss das Programm die Datei neu Schreiben,
aufgrund deiner Aussage vermute ich, dass MP3Tag die ganze Datei als Block in den Speicher laden will GetMem(p, filesize(f)) .... ?
Das wird bei der Dateigröße bei einem 32 Bit Prozess knapp weil er nur eine gewisse Speichermenge allokieren kann.
Ich versteh aber nicht, warum er so große Dateien nicht Blockweise schreibt...

Lösung a:
Evtl. mal über ein anderes Dateiformat nachdenken

Lösung b:
MP3Tag sollte Blockweise arbeiten

Gruß,
Peter


poster
ZITAT(nikopet @ Mar 27 2017, 05:48) *
Ich habe eine CD mit 192/24 gerippt; die daraus entstehende WAV-Datei hat 2,2 GB.

Wie hast Du die Dateien erzeugt?
Manche Software kann keine Wave-Files größer als 2 GB korrekt schreiben.

https://hydrogenaud.io/index.php/topic,92030.0.html
nikopet
ZITAT(MP3Freak_Peter @ Mar 27 2017, 18:49) *
kurze Frage vorab, warum verwendset du WAV und nicht FLAC? ohmy.gif huh.gif
Rippst du SuperAudio CDs?

Zum Problem:
Zum ändern des Tags muss das Programm die Datei neu Schreiben,
aufgrund deiner Aussage vermute ich, dass MP3Tag die ganze Datei als Block in den Speicher laden will GetMem(p, filesize(f)) .... ?
Das wird bei der Dateigröße bei einem 32 Bit Prozess knapp weil er nur eine gewisse Speichermenge allokieren kann.
Ich versteh aber nicht, warum er so große Dateien nicht Blockweise schreibt...

Lösung a:
Evtl. mal über ein anderes Dateiformat nachdenken

Lösung b:
MP3Tag sollte Blockweise arbeiten

Gruß,
Peter


Hallo Peter,
selbst, wenne s merkwürdig klingt, ich verwende WAV, weil es für mich nach vielen vielen vielen Hörsitzungen immer noch besser klingt als FLAC... auch wenn es technisch kaum erklärbar ist; ich habe aber diesbezüglich ein interessantes Statement gefunden, USA genaue Adresse ahbe ich nicht meht.... Aber das ist doch keine Begründung ;-)))
Mein Prozessor arbeitet mit 64 bit und ich habe 8 GB RAM das sollte also auch kein Problem sein...
Also wiederhole ich meine Frage: hat Mp3tag irgendwo - wie früher Windows - eine Beschränkung bezüglich der Dateigröße?

nikopet
ZITAT(poster @ Mar 27 2017, 19:06) *
Wie hast Du die Dateien erzeugt?
Manche Software kann keine Wave-Files größer als 2 GB korrekt schreiben.

https://hydrogenaud.io/index.php/topic,92030.0.html


mit dbpoweramp CD-ripper
ohrenkino
ZITAT(nikopet @ Mar 28 2017, 20:55) *
...
Mein Prozessor arbeitet mit 64 bit und ich habe 8 GB RAM das sollte also auch kein Problem sein...

MP3tag ist eine 32-Bit-Anwendung und unterliegt damit der 4GB-Beschränkung. Aber das haben die anderen Poster auch schon geschrieben.
MP3Freak_Peter
QUOTE (ohrenkino @ Mar 28 2017, 20:58) *
MP3tag ist eine 32-Bit-Anwendung und unterliegt damit der 4GB-Beschränkung. Aber das haben die anderen Poster auch schon geschrieben.

da muss ich dir widersprechen ist theorie - 2^32,
praktisch ist zumeist bei 2 bzw. 3 GB Schluss abhängig vom Betriebssystem
MP3Freak_Peter
QUOTE (ohrenkino @ Mar 28 2017, 20:58) *
MP3tag ist eine 32-Bit-Anwendung und unterliegt damit der 4GB-Beschränkung. Aber das haben die anderen Poster auch schon geschrieben.

für das neu schreiben der Datei ist es nicht notwendig die ganze Datei in den Speicher zu laden,
sie kann auch blockweise umgespeichert werden und wenn die neue temp datei komplett ist, kann diese das Original ersetzen.
Die ganze Datei in den Speicher zu laden ist die denkbar ungünstigste Lösung was aber augenscheinlich gertan wird.
Die Frage ist hier, hat Florian Zugriff darauf oder verwendet er externe Taglibs.
ohrenkino
ZITAT(MP3Freak_Peter @ Mar 28 2017, 21:09) *
da muss ich dir widersprechen ist theorie - 2^32,
praktisch ist zumeist bei 2 bzw. 3 GB Schluss abhängig vom Betriebssystem

4GB sind meiner Ansicht nach 2^32.
Der Adressraum ist damit 4 GB.
Dass sich darin auch noch OS-Routinen tummeln und was weiß ich nicht noch alles, ist hier völlig akademisch, da der OP den Eindruck hat, dass sein 64-BIT-OS nicht
ZITAT
wie früher Windows
einer Speicherbegrenzung unterliegt.
De facto unterliegt auch dieses (64-bit-)Windows einer Grenze: 2^64.
Die ist zwar ein Stück weiter weg, aber es gibt sie.

Viel wichtiger erscheint mir in diesem Zusammenhang, festzuhalten, dass die riesige Datei vermutlich genau wg. des verfügbaren Adressraums nicht gehandhabt werden kann.
Das ist dann allerdings keine typische MP3tag-Beschränkung, sondern der binären Architektur geschuldet.

Falls es dich beruhigt, hier eine meiner Antworten zur 32-bit-Problematik: https://forums.mp3tag.de/index.php?showtopic=21682
MP3Freak_Peter
QUOTE (ohrenkino @ Mar 28 2017, 21:18) *
4GB sind meiner Ansicht nach 2^32.
Der Adressraum ist damit 4 GB.
Dass sich darin auch noch OS-Routinen tummeln und was weiß ich nicht noch alles, ist hier völlig akademisch, da der OP den Eindruck hat, dass sein 64-BIT-OS nicht einer Speicherbegrenzung unterliegt.
De facto unterliegt auch dieses (64-bit-)Windows einer Grenze: 2^64.
Die ist zwar ein Stück weiter weg, aber es gibt sie.

Viel wichtiger erscheint mir in diesem Zusammenhang, festzuhalten, dass die riesige Datei vermutlich genau wg. des verfügbaren Adressraums nicht gehandhabt werden kann.
Das ist dann allerdings keine typische MP3tag-Beschränkung, sondern der binären Architektur geschuldet.

Falls es dich beruhigt, hier eine meiner Antworten zur 32-bit-Problematik: https://forums.mp3tag.de/index.php?showtopic=21682


das 2^32 4294967296 ergibt bestreitet hier keiner, ABER abhängig vom Betriebssystem ist der virtuelle Adressraum pro Prozess noch mal weiter beschränkt.
Diese Beschränkung ist nicht mp3tag spezifisch, das ist richtig, ABER, an dieser Stelle (neu schreiben EINER Datei) wäre es programmtechnisch nicht nötig überhaupt in diese Begrenzung zu laufen.

Zumdem ist es ja völlig legetim für solche Aktionen temporär Daten abzulegen,
ein ZIP Programm z.B. wird dir beim Erstellen einer ZIP Datei auch immer ne Temp Datei schreiben und die dann auf's Ziel kopieren sobald alles hinzugefügt wurde anstatt alles in den Speicher zu klopfen.

Der Verlinkte Topic behandelt das Einlesen vieler Dateien, auch da ist natürlich zu hinterfragen,
was muss mp3tag alles im Speicher haben und halten.
Ich weiß, mp3tag will keine Datenbank, mp3tag bearbeitet Datei für Datei, aber er hällt sich ja doch Daten pro Datei, aber muss das denn alles incl. Cover sein?
Ich denke da ist durchaus Optimierungspotential. Ich gebe hier lediglich Anregungen.

Gruß,
Peter


ohrenkino
ZITAT(MP3Freak_Peter @ Mar 28 2017, 21:53) *
...Der Verlinkte Topic behandelt das Einlesen vieler Dateien, auch da ist natürlich zu hinterfragen,
was muss mp3tag alles im Speicher haben und halten.
Ich weiß, mp3tag will keine Datenbank, mp3tag bearbeitet Datei für Datei, aber er hällt sich ja doch Daten pro Datei, aber muss das denn alles incl. Cover sein?
Ich denke da ist durchaus Optimierungspotential. Ich gebe hier lediglich Anregungen.

Gruß,
Peter

Du stellst Fragen, gibst aber nicht wirklich Anregungen:
Wie soll ein Filter mit
%_fieldname% PRESENT
funktionieren, wenn nicht auch die Daten vorliegen?
Weißt du, dass die Bilder in voller Schönheit mit im Speicher sind? Ich weiß es nicht, da ich dazu noch keine Aussage von der Programmiererseite gehört habe.

Eine Datenbank ist nicht eine Frage des Wollens, sondern eine Frage des Sinns: Datenbanken machen dann Sinn, wenn die eingelesenen Daten wiederholt abgerufen werden und mehr oder weniger fix sind.
Beim Taggen ist aber genau das Gegenteil der Fall: da gibt es gar keine, wenige oder falsche Daten, die am Ende des Vorgangs des Taggens in einem (hoffentlich) endgültigen Zustand sind. Jetzt braucht man den Tagger nicht mehr, ab jetzt ist die Datenbank sinnvoll.
Eine Datenbank erst anzulegen, ohne die Garantie zu haben, dass die Daten noch gültig sind bei der nächsten Benutzung (iTunes-Benutzer können ein Lied davon singen, wie mühsam es ist, eine umfangreiche Bibliothek zu aktualisieren, das kann Stunden dauern), ist in meinen Augen Zeitverschwendung, da sowieso erstmal alle Daten frisch gelesen werden müssen - und dann können die auch im Speicher landen.
Hier ist es besser, wenn der Anwender seinen Arbeitsablauf optimiert und ressourcenschonende Prozesse entwickelt. Im Zusammenspiel mit anderen Programmen (foobar, WMP, iTunes) ist MP3tag ein super Modul für genau die spezialisierte Aufgabe des Taggens.
Es ist kein Verwaltungsinstrument für komplette Sammlungen - dafür gibt es andere Programme.

Zurück zum eigentlichen Problem: mich würde mal interessieren, wie andere Programme zum Editieren des Audioteils beim Bearbeiten solch riesiger Dateien zurecht kommen.
MP3Freak_Peter
ok, ich versuch mal zu den einzelnen Punkten gezielt Feedback zu geben.

>>Wie soll ein Filter mit %_fieldname% PRESENT funktionieren, wenn nicht auch die Daten vorliegen?
es gibt wunderschöne embedded Datenbanken, die sich auch für temporäre Datenmengen eignen
(nimmt auch gleich das mit dem Sinn und Unsinn einer Datenbank vorweg)
Ob die Daten nun in einer internen eigenen Struktur gehalten werden die mehr oder weniger optimal mit Speicher und performance umgeht oder ob man eine kleine Embedded Datenbank nutzt kommt auf selbe raus. So oder So hast du die Datenmenge temporär im speicher und durchsucht sie.
Nur das eine Embedded Datenbank nicht alles im Speicher haben muss sondern - die klassische relationale Datenbank - nur die Teile (INDEX) im Speicher hat die performant vorhanden sien müssen, wobei alles andere auch durchaus einigermaßen performant geht.
Mir ist durchaus bewusst, das MP3Tag aufgrund seiner Vielfalt sehr viele Daten halten muss,
Komprimiert mp3tag die Daten im Speicher? verwendet es UTF8 oder gar unsinigerweise UTF-16?
Der Teufel steckt bei sowas im Detail, glaubs mir oder net smile.gif

>>...da sowieso erstmal alle Daten frisch gelesen werden müssen - und dann können die auch im Speicher landen....
Ein permanentes halten von Daten, macht beim Taggen keinen Sinn, sehe ich auch so,
aber siehe oben, wenn die temporären Daten so viel sind, muss man sich schon genau überlegen wie und wo man sie organisiert.

>>Weißt du, dass die Bilder in voller Schönheit mit im Speicher sind?
Ja weiß ich leider, könnt man mit dem Begriff Sch**** oder ähnlich umschreiben wenn du versehst was ich meine.
Nur da man auf %BILD% nicht filtern kann, sehe ich keine Notwendigkeit das für jede Datei direkt im Speicher zu halten.
(Metainformationen zum Bild wie größe z.B. darüber kann man reden)

>>Ich weiß es nicht, da ich dazu noch keine Aussage von der Programmiererseite gehört habe.
ja hau ihn doch mal an, ich würde es Begrüßen, wenn er sich hier direkt in die Debatte einklinkt,
ich glaub schon, dass wir uns "verstehen", auch wenn wir nicht die selbe Programmiersprache verwenden. Hier gehts um Technik jenseits davon.

>>...MP3tag ein super Modul für genau die spezialisierte Aufgabe des Taggens.
Es ist kein Verwaltungsinstrument für komplette Sammlungen - dafür gibt es andere Programme.

Mediapurge (sorry, den konnt ich mir grad net verkneifen)

>>Zurück zum eigentlichen Problem: mich würde mal interessieren, wie andere Programme zum Editieren des Audioteils beim Bearbeiten solch riesiger Dateien zurecht kommen.
hab ich oben doch schon erklärt, blockweises schreiben in eine tempdatei, und wenn die fertig ist die originaldatei mit der tempdatei ersetzen.

pseudocode:
öffne quelldatei
öffne tempdatei
solange noch daten in der quelldatei {
lese block aus quelldatei
wenn block zu tag gehört, editiere block (sehr blümerant erklärt da der tag ja meist vorn oder hinten ist)
schreibe block in tempdatei
}
schließe quelldatei
schließe tempdatei
move tempdatei auf quelldatei

alternativ kann auch die quelldatei erst auf temp geschoben werden und in die quelldatei geschrieben werden, der oben beschriebene weg ist aber der sicherste.

SO und jetzt kommen wieder die User die die Datei abspielen während das Taggen läuft,
mp3tag scheint da sowieso etwas komisch zu machen weil nach dem Prinzip die Datei entweder geschrieben werden kann (im ganzen) oder garnicht.

So, mein Weingläschen ist nun leider leer, daher hau ich mich jetzt auf's Ohr,
würd mich aber freuen wenn das hier irgendwie an die richtige Stelle gelangt (Florian)
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2017 Invision Power Services, Inc.