mp3fs für FreeBSD

zuglufttier

Well-Known Member
Ahoi,

hat vielleicht jemand von euch schon mal mp3fs[1] zum laufen gebracht? Das Programm ist ganz interessant für Menschen, die ein Musikarchiv mit FLAC-Dateien haben und für den MP3-Player z.B. noch extra MP3s haben wollen und diese Geschichte nicht extra pflegen wollen.

Ich zähle mich zu diesen Menschen, fühle mich aber nicht in der Lage die Software für FreeBSD zu übersetzen... Wäre vielleicht als Port interessant. Unter NetBSD[2] ist das auch schon verfübar.

[1] - http://mp3fs.sourceforge.net/
[2] - http://pkgsrc.se/filesystems/fuse-mp3fs
 
Hallo zuglufttier,

mp3fs hatte ich auch mal auf dem Radarschirm, da es aber nicht in den Ports war, habe ich es wieder verworfen. Eine Alternative dazu ist sysutils/fuse-gstfs. Das ist gstreamer-basiert und noch flexibler. Man soll damit die bekannten gstreamer-Pipelines verwenden können. Das hat bei mir nie geklappt, die Pipelines funktionierten mit gstreamer, aber gstfs hat trotzdem nicht wirklich damit funktioniert. Das Mounten klappte, ich konnte auch die mp3-Files sehen, aber beim kopieren/lesen passierte nix.
Das ist aber schon fast 2 Jahre her, habe es dann nicht weiterverfolgt. Das Prinzip ist ansonsten ähnlich zu mp3fs.

Gruß c.
 
Hat es einen Vorteil, wenn man VFS für solche Sachen einsetzt? Ich habe einfach mt-daapd hier am Laufen. Das transkodiert auch on the fly.

Es gibt noch das neuere firefly in den Ports (Fortsetzung von mt-daapd). Nur leider tut es nichts und stürzt nur ab.
 
Ich habe nicht viel Hoffnung, die Software kommt aus 2008 ;)

mp3fs wird aktuell noch entwickelt, von daher wäre das schon sehr interessant... Ich konnte übrigens Version 0.13 mit diesen Tipps [1] bauen und auch ausführen. Beim Zugriff auf das neue Verzeichnis aber war's das. Sprich, ich bekomme keine Antwort. Zudem ist Version 0.30 aktuell und damit komme ich überhaupt nicht weiter...

[1] - http://www.daemonforums.org/showthread.php?p=28120
 
Hat es einen Vorteil, wenn man VFS für solche Sachen einsetzt? Ich habe einfach mt-daapd hier am Laufen. Das transkodiert auch on the fly.

Es gibt noch das neuere firefly in den Ports (Fortsetzung von mt-daapd). Nur leider tut es nichts und stürzt nur ab.

Keine Ahnung... Mir ist die Funktionsweise nicht ganz klar.

Ich möchte im Endeffekt einfach einen Ordner mit MP3-Dateien haben, welche dann per SMB im Netzwerk bereitgestellt werden.
 
Naja. mt-daapd stellt Audiodateien abspielbar für MP3-Player dar. Das geht per DAAP (Netzwerkprotokoll). Das ist vor allem bekannt bei dem Apple-Zeug und sollte kompatibel sein.

Ich benutze als Client rhythmbox. Das kann mit DAAP umgehen und zeigt mir die Lieder sortiert in Alben oder nach Autoren an. Naja, korrekte ID3-Infos müsste man halt haben, dann würde es perfekt klappen. :)
 
So wie ich zuglufttier verstanden habe, möchte er gerne seinen mp3-Player betanken, das dürfte mit dem daap-Geraffel nicht gehen. Zum reinen Abspielen der Songs kann man es natürlich verwenden.

Gruß c.
 
Zuletzt bearbeitet:
Richtig, ich möchte z.B. meinen MP3-Player betanken und dafür nicht extra alles als MP3 umwandeln, um mir auch die doppelte Pflege der Daten zu ersparen.

Zudem würde so ne Umwandlung jetzt beim ersten Mal mehrere Tage dauern...
 
Ich möchte gerade meine Sammlung neurippen in FLAC und wollte auch alle FLAC als Vorbis vorhalten, für mobile Geräte etc. Ich hatte mir dazu eine (etwas komplizierte) Lösung mit Sh vorgestellt, aber wenns dafür ein virtuelles Dateisystem gibt wäre das natürlich super.
Geht denn mp3fs nur mit MP3?
 
Mp3fs scheint bisher nur mit lame als Encoder zu funktionieren. Mir würde auch ogg oder was ähnliches genügen. In der Theorie müssten die Dateien ja noch ein bisschen kleiner sein. Letztendlich kommt's mir aber nur auf die Kopiergeschwindigkeit an. Ich möchte einfach "mal eben schnell" ein, zwei Alben rüberkopieren können.
 
Unter KDE3 gab es so etwas mal mit KIO.
Beispiel: AudioCD einlegen, CD wird gemounted, auf der CD gibt es dann Ordner mit allen Tracks als mp3, flac, ogg, ...
Wie das heute ausschaut, oder ob man das auch auf ein normales beliebiges Verzeichnis anwenden kann weiß ich allerdings nicht.
 
Ich warte auf den ersten der seine Lieblingsversionsverwaltung mit passenden Postcommithooks (und vllt. mehreren Branches) vorschlägt.
 
Ich rippe meine CDs auch als FLAC-Files. Dann werden die Tags nachbearbeitet und die Cover eingebettet. Dann lasse ich ein ShellScript drüberlaufen, das mir alle FLAC-Files, die neuer sind als eine Referenzdatei, konvertiert. Am Ende des Scripts wird mit touch das Datum der Referenzdatei und aller Musik-Dateien gesetzt. Das mit der Referenzdatei mache ich, weil ich schon öfter Tags nachbearbeitet habe und dann die mp3's automatisert generieren ließ.

Den eigentlichen Konvertierjob mache ich mit gstreamer, da ich die pipeline noch aus meinen gstfs-Versuchen hatte und es die Möglichkeit bietet, die ID3-Tags aus den Quell-Datein zu extrahieren und in wieder in die Ziel-Dateien zu integrieren.

Die mp3's belegen bei mir 30GB, hält sich noch in Grenzen und durch das Script auch die Arbeit.

Gruß c.
 
Hallo zuglufttier, Hallo Community

Ich habe hier seit gestern mp3fs auf FreeBSD 9.0-RELEASE am laufen. Falls Interesse besteht kann ich noch nähere Details posten.
 
Nun denn,

Das bauen von mp3fs-0.31 war relativ einfach.
Vorraussetzung ist, daß die Pakete audio/lame und audio/flac sowie sysutils/fusefs-libs und sysutils/fusefs-kmod installiert sind.

Zuerst hab ich die CFLAGS angepasst.
Code:
export CFLAGS="-L/usr/local/lib -I/usr/local/include"

Im Quellpaket mußte ich die Datei sys/mp3fs.c patchen.

Nach
Code:
#include "transcode.h"
hab ich
Code:
#define	S_ISLNK(m)	(((m) & 0170000) == 0120000)
#define	S_ISSOCK(m)	(((m) & 0170000) == 0140000)
eingefügt, da beim bauen folgender Fehler auftrat
Code:
mp3fs.o: In function `mp3fs_readdir':
mp3fs.c:(.text+0x2d7): undefined reference to `S_ISLNK'
*** Error code 1

Ob dieser Patch "Regelkonform" ist weiß ich aber nicht. In der Headerdatei sys/stat.h steht nämlich folgendes:
Code:
#if __POSIX_VISIBLE >= 200112
#define	S_ISLNK(m)	(((m) & 0170000) == 0120000)	/* symbolic link */
#define	S_ISSOCK(m)	(((m) & 0170000) == 0140000)	/* socket */
#endif
Was dieses __POSIX_VISIBLE >= 200112 bedeutet müßte einer der Guru's hier im Forum sagen. Ob das Programm nach Anwendung dieses Patches nocht richtig funktioniert kann ich auch nicht sagen. Aber es läßt sich so wenigstens kompilieren.

Dann kann das Paket ganz normal gebaut werden.
Code:
./configure
make
make install

Noch ein Eintrag in die /etc/rc.conf
Code:
fusefs_enable="YES"
FUSEFS starten mit
Code:
/usr/local/etc/rc.d/fusefs start
Dann kann mp3fs auch schon verwendet werden.
z.B.:
Code:
mp3fs -b 192 /mnt/flac /mnt/mp3 -o ro

Ich hab mal "schnell" einen Port gebastelt um das ganze etwas einfacher zu machen. Dieser hat aber noch das Problem, das es das Quellpaket nicht herunterlädt. Keine Ahnung warum. Das müßte auch einer der Guru's hier sagen.
Wenn das Quellpaket aber in /usr/ports/distfiles liegt sollte alles bauen.

Testen auf eigene Gefahr! Am besten in einer Jail oder VM.
 

Anhänge

Danke laemodost für die Mühe.

Bevor ich aber einen PR verfasse möchte ich noch wissen ob mein Patch so in Ordnung geht, oder ob es ein absolutes No-Go ist, da ich ja eigentlich damit etwas umgehe, das in der sys/stat.h durch die if Abfrage nicht möglich wäre.

Außerdem werd ich aus dem ganzen POSIX Zeugs hier nicht schlau.
 
Ich wollte eben einen PR erstellen. Wenn ich jedoch das Webformular ausfülle und die shar Datei auswähle kommt beim abschichen folgender Fehler:
Code:
There is an error with your problem report submission. The problem was: 

Patch file has wrong content type: got application/octet-stream but was expecting one matching text/.* or application/shar.

Try renaming the file to have a .txt extension to convince your browser to do the right thing.
.

Was nun?
 
Zurück
Oben