MP3 Daten im BLOB Feld speichern und auslesen

[Lorca]

Hallo zusammen,

gerne würde ich *.MP3 Dateien in das Blobfeld einer SQLITE-3 DB-Tabelle
speichern und auch wieder auslesen können. Leider haben alle meine diesbezüglichen Versuche nichts gebracht.

Das Blobfeld ist mit der Kollation: BINARY definiert.

Ist es möglich, dann die MP3 Daten aus dem Blobfeld direkt über die BASS Unit abzuspielen, oder muss erst eine
temporäre MP3 Datei aus dem Blobfeld angelegt werden?


Kann hierzu jemand etwas sagen?


Viele Grüße

Lorca

[theo]

Kann hierzu jemand etwas sagen?

Würde ich als Datei speichern und nur den Pfad in die DB schreiben.
Die Binärdaten haben ja keinen Sinn in der DB, oder willst du nach Bytes suchen?

[Winni]

Hi!

Bass kann abspielen

* Eine Datei
* Einen URL-Stream
* Eine CD

Andere Möglichkeiten sind mit nicht bekannt.

Verfolge doch Theos Ansatz und speicher Dateinamen mit Pfad.

Anderweitig musst Du aus dem Blob-Feld erst eine temporäre Datei erzeugen und die abspielen. Zeit- und Platzverschwendung.

Winni

[Winni]

Hi!

Es gibt doch vielleicht eine Möglichkeit, aber ich hab's noch nie probiert: http://www.un4seen.com/doc/#bass/BASS ... eUser.html

Code: Alles auswählen

HSTREAM BASS_StreamCreateFileUser(
    DWORD system,
    DWORD flags,
    BASS_FILEPROCS *procs,
    void *user
);

Dafür musst Du einen Stream aus der Blob-Feld der DB erzeugen und deine Function als Parameter BASS_FILEPROCS übergeben.

Winni

[charlytango]

gerne würde ich *.MP3 Dateien in das Blobfeld einer SQLITE-3 DB-Tabelle
speichern und auch wieder auslesen können. Leider haben alle meine diesbezüglichen Versuche nichts gebracht.

Das Blobfeld ist mit der Kollation: BINARY definiert.

Ist es möglich, dann die MP3 Daten aus dem Blobfeld direkt über die BASS Unit abzuspielen, oder muss erst eine
temporäre MP3 Datei aus dem Blobfeld angelegt werden?


Kann hierzu jemand etwas sagen?

Ohne dir sagen zu wollen was du tun sollst....

Binärdaten in eine DB zu speichern macht für mich im größeren Stil wenig Sinn.
Die Gründe haben winnie und theo schon ausgeführt.
Außer für Spezialanwendungen macht das wohl keinen Sinn, denn ich kenne keinen Player der auf SQL-Speicherung setzt (außer vielleicht bei der Speicherung von Metadaten und Playlisten etc.)

Außer du verfolgst ein akademisches Interesse würde ich die Speicherung von MP3 in der Verzeichnisstruktur belassen und gegen die Synchronisierung des Zugriffspfades tauschen.

[Lorca]

Hallo zusammen,

erst einmal herzlichen Dank für eure Antworten.

Der Sinn zum Speichern der MP3 Daten in ein Blobfeld liegt in der Datensicherung der DB und auch in der Mobilität.

Derzeit werden bereits die Pfade und Dateinamen in der DB gespeichert . Hier ist jedoch das Problem das bei jeder Datensicherung alle Pfade und MP3 Files zusätzlich zur DB gesichert werden müssen.
Ebenfalls geht die "Kopier Orgie" los, wenn die DB auf einem anderen Rechner ( Notebook ) geladen werden sollen.
Die Datenspeicherung in eine Cloud ist keine Option. Ebenfalls entfällt auch die Änderung auf eine Multi User DB bzw. Netzwerk DB.

Weiter würde ich halt gerne wissen, wie ein TFileStream in ein Blobfeld geladen und auch wieder herausgeholt werden kann.
Bilder sind schließlich auch nur binäre Stream Daten. Und hier hier funktioniert es ja auch. Dies erledigt jedoch die Komponente: TDBImage.
Leider werde ich hier jedoch nicht schlau draus.

Ein Temporärer File stream, erstellt aus den Binärdaten des Blob Feldes, wäre akzeptabel, wenn auch nicht sonderlich elegant.

Die elegantere Lösung z.B. einen Stream aus dem Blobfeld zu erzeugen wie von winni vorgeschlagen, um diesen dann direkt mit der BASS abzuspielen, kann ich jedoch erst dann in Angriff nehmen wenn ich weiß wie die Daten eines File Streams in ein Blobfeld ein und ausgelesen werden können.


Viele Grüße

Lorca

[six1]

Hi,
mit einem Image geht es so:

Code: Alles auswählen

var
  BlobStream : TStream;
begin
    Screen.Cursor:= crSQLWait;
    BlobStream := CreateBlobStream(SQLQuery1.FieldByName('Contents'),bmRead);
    BlobStream.Position:= 0;
    Image1.Picture.LoadFromStream(BlobStream);
    Screen.Cursor:= crDefault;
    BlobStream.Free;
 end
  

Jetzt musst du es nur noch anpassen...

[charlytango]

Der Sinn zum Speichern der MP3 Daten in ein Blobfeld liegt in der Datensicherung der DB und auch in der Mobilität.

Derzeit werden bereits die Pfade und Dateinamen in der DB gespeichert . Hier ist jedoch das Problem das bei jeder Datensicherung alle Pfade und MP3 Files zusätzlich zur DB gesichert werden müssen.
Ebenfalls geht die "Kopier Orgie" los, wenn die DB auf einem anderen Rechner ( Notebook ) geladen werden sollen.

Keine Ahnung wie du das handhabst, aber meine Musik umfasst so in etwa 750GB bei rund 160.000 Tracks.

Die ganze Musiksammlung liegt physisch in einem Verzeichnis und von dort ausgehend in etlichen gestaffelten Unterverzeichnissen.

In einer Datenbank würde ich neben dem absoluten Pfad immer auch einen relativen Pfad mitspeichern.
Dann ist das verschieben auf ein anderes Laufwerk oder Server bzw Notebook nur ein SQL Statement das aus dem relativen Pfad in den Track-Records in Verbindung mit dem neuen Speicherort den absoluten Pfad in die DB schreibt und alles ist wieder synchron.

Vorteil der Dateimethode ist, dass praktisch jeder Player auf dem Markt (sofern die Tags in den dateien korreckt sind) sich seine eigene Datensammlung zusammensucht und auch abspielen kann.
Ist das alles in einer echten SQL-Datenbank ist das Backup noch komplexer und auch auf dem Zielrechner muss das alles erst installiert werden. (Außer es ist eine Desktop DB wie zb SQLite, aber dann ist das ja auch nur das Kopieren einer Datei.)

Keine der professionell verfügbaren Lösungen (eben solche die ich kenne) setzt auf Binäre Daten in einer DB. Auch im Netzwerk nicht.

Ich benutze meine Musiksammlung auch professionell (Tanzleher) auf unterschiedlichen Rechnern und mit unterschiedlichen Betriebssystemen. (Windows, MacOS, iPod, Android) und demnach auch unterschiedlichen Playern.
Der Single Point Of Reference sind bei mir die Tags direkt in der MP3 Datei bzw die M3U Playlisten.

Die Tags bearbeite ich mit MP3Tag das es mittlerweile auch unter MacOS gibt. Nachdem ich gesehen habe welche Fähigkeiten das Programm hat (samt scripting, Bulk-Renaming etc etc) hab ich gleich die Finger von der Idee gelassen etwas eigenes zu Programmieren.
Da stecken Mannjahre Erfahrung drin.

Have Fun... just 2 cents

[Winni]

Keine Ahnung wie du das handhabst, aber meine Musik umfasst so in etwa 750GB bei rund 160.000 Tracks.

Die ganze Musiksammlung liegt physisch in einem Verzeichnis und von dort ausgehend in etlichen gestaffelten Unterverzeichnissen.

.....
Vorteil der Dateimethode ist, dass praktisch jeder Player auf dem Markt (sofern die Tags in den dateien korreckt sind) sich seine eigene Datensammlung zusammensucht und auch abspielen kann.
Ist das alles in einer echten SQL-Datenbank ist das Backup noch komplexer und auch auf dem Zielrechner muss das alles erst installiert werden. (Außer es ist eine Desktop DB wie zb SQLite, aber dann ist das ja auch nur das Kopieren einer Datei.)

Keine der professionell verfügbaren Lösungen (eben solche die ich kenne) setzt auf Binäre Daten in einer DB. Auch im Netzwerk nicht.

Hi!

Ich hab zwar nur 1/3 deines Repertoires und nutze es nur für den Privatgebrauch, aber ich stimme Dir zu:

Eine DB für mp3-Dateien ist extrem unpraktisch, Bei einem vernünftig gepflegten Dateibaum hat man alle Songs sofort greifbar und falls nicht : man hat alle Funktionen der shell für den Einsatz, Linux in meinem Fall. Mit find oder -ls -1R | grep... kann man schnell alles absuchen lassen, ohne eine DB zu bemühen, die erfahrungsgemäß langsamer ist.

Außerdem kommt hinzu, das mp3-Dateien derart komprimiert sind, dass manche Kompressions-Algorithmen sogar das Original um 1 bis 2 % vergrößern.

Wichtig ist ein von Hand gepflegter Dateibaum, der z.B. erstmal das "The" vor dem Bandnamen löscht . Außerdem muss man sich Gedanken machen, ob man Duplikate von den "Best of" -Alben mitschleppen will oder sie durch Links ersetzt. Früher war das sinnvoll, heute kostet Festplatten-Platz nix mehr.

Winni

[af0815]

Es gibt professionelle Lösungen für das Speichern von Dateien am/mit DB-Server.
Siehe https://docs.microsoft.com/de-de/sql/re ... rver-ver15
Insgesamt ist das sehr speziell.

[wp_xyz]

Auch wenn ich ebenfalls der Meinung bin, dass große Datenblöcke wie Musikdateien oder Bilder im Dateisystem bleiben sollten, hier im Anhang eine kleine auf SQLite3 basierende und mit BASS abspielbare Musik-DB - nur das allernötigste aber:
- "Add": eine neue mp3-Datei in die Datenbank schreiben
- "Play": das aktuell im DBGrid angewählte Stück spielen
- "Stop": das Abspielen beenden.
- "Pause": das Abspielen anhalten
- "Resume": das Abspielen fortsetzen
- sowie einen Lautstärkeregler.

Das ist unter Windows geschrieben und getestet. Achtung: Man braucht die BASS.dll und sqlite3.dll im Verzeichnis der Anwendung in 32 bzw 64 bit, je nachdem was der Compiler erzeugt hat.

[charlytango]

Bin beeindruckt von eurem Engagement um eine Lösung, obwohl ihr weitgehend meiner Meinung seid.

Lazarusforum at its best !
Kompliment!

Möchte mich nur vorsichtshalber entschuldigen falls ich jemandem ob meiner Vehemenz auf die Zehen getreten sein sollte, ich reagiere nur heftig drauf in einer relationalen DB unstrukturierte Inhalte abzulegen.

Zudem muss ich noch immer mit einem Kassensystem zurecht kommen bei dem einige Schwachmaten Daten in Form von XML-Strukturen in DB-Textfeldern gestopft haben als quasi Untertabellen. Mit dem Ergebnis dass man nicht per SQL-Statements die Daten benutzen kann. Das sensibilisiert. Mögen die EDV Götter diese Möchtegerndesigner in heikle Stellen beißen

[af0815]

Zudem muss ich noch immer mit einem Kassensystem zurecht kommen bei dem einige Schwachmaten Daten in Form von XML-Strukturen in DB-Textfeldern gestopft haben als quasi Untertabellen. Mit dem Ergebnis dass man nicht per SQL-Statements die Daten benutzen kann.

Ich glaube das kommt aus dem MSSQL-Server,

https://docs.microsoft.com/en-us/sql/re ... rver-ver15
https://www.sqlshack.com/working-with-x ... ql-server/

der kann damit umgehen. Ich habe das in der freien Wildbahn bereits gesehen und musste/durfte damit vor ein paar Jahren arbeiten. Am MS-SQL Server relativ einfach, wo anders gebe ich dir recht, ein Horror.

Nur so nebenbei, den MS-SQL Server gibt es mittlerweile auch für Ubuntu und verhält sich exakt so wie der Windows basierende. Auch die Administrierung/Verwaltung - von Windows aus mit dem MSSMS - ist komplett gleich. Der kleine Server ist wie unter Windows kostenfrei, mit den gleichen Einschränkungen. Installationszeit für den Server liegt bei mir unter 10 min. Ich habe aber Übung.

[Lorca]

Hallo zusammen,

ganz herzlichen Dank für eure vielen Antworten und euer Engagement.

Leider weiß ich immer noch nicht wie ich es bewerkstellige, einen gelesenen Filestream in ein Blobfeld zu überführen und auch wieder aus einem Blobfeld in einen Filestream bekomme. Ich denke ich habe mich nicht deutlich genug ausgedrückt.

In meinem Post war die Rede von MP3 Dateien, ihr habt jedoch Musik Dateien hinein interpretiert.
Diese Funktion wird jedoch für kurze Audiokommentare und nicht für Musik Dateien benötigt.
Außerdem ist der Inhalt der MP3 Files völlig egal, da meine Frage auf das "Wie wird das gemacht?" abzielt.

Wie ich einen RessourcenStream erstelle ist mir klar. Und auch das war nicht meine Frage.
Z.B. könnte mit meinen dummen Worten eine solche Antwort so aussehen:
MOVE Ressourcenstream TO Blobfeld oder zurück: MOVE BlobFeld TO Ressourcenstream


Dieser Pseudocode funzt natürlich nicht in der dargestellten Schreibweise nicht. Veranschaulicht jedoch meine Frage ungemein.
Wie bekomme ich also einen RessourcenStream in ein Blobfeld und umgekehrt?

Kann hier jemand etwas zu sagen?



Viele Grüße und nochmals herzlichen Dank für eure netten Antworten
Lorca

[six1]

ich habe dir doch, zumindest für bmRead, Code gezeigt:
viewtopic.php?p=125221#p125221