Seite 1 von 1
Schlanke Musik-Library
Verfasst: Montag 9. Mai 2011, 12:04
von ravenheart
Hallo, ich suche eine Library, mit der ich
MP3, WAV, MIDI, OGG und FLAC (alles weitere ist umso besser)
ganz einfach abspielen, pausieren , rewinden, stoppen (Halt normale PlayerFunktionen) kann.
PyMedia krieg ich einfach nicht installiert und PyGame ist zwar super aber vielleicht einwenig zu groß.
Gstreamer zB ist mir schon wieder viel zu komplex, und von openAL will ich gar nicht reden =)
Und welchen Tag-Editor könnt ihr empfehlen?
Möchte MP3 und alles oben gennant, das Tags hat bearbeiten können.
Herzlichen Dank im Voraus
Re: Schlanke Musik-Library
Verfasst: Montag 9. Mai 2011, 12:31
von Xynon1
Einerseits suchst du eine Bibliothek und andererseits zählst Python Pakete auf. Dann möchtest du, dass das Paket/Framework weder zu komplex, als auch nicht größer als 8MB (entpacktes pygame) ist.
Was genau suchst du jetzt eigentlich? bzw. erwartest du zu finden ?
Re: Schlanke Musik-Library
Verfasst: Montag 9. Mai 2011, 12:53
von deets
Ich hab' gerade angefangen mit pyaudio rumzuspielen, sah gut aus.
Re: Schlanke Musik-Library
Verfasst: Montag 9. Mai 2011, 13:01
von ravenheart
Was ist eig genau der Untershcied Bibliothek/Paket?
Ich denke bei beidem an das selbe
Re: Schlanke Musik-Library
Verfasst: Montag 9. Mai 2011, 13:16
von Xynon1
Ja, im Prinzip schon, nur kenn ich keine Audio-Bibliothek die direkt in Python geschrieben ist. Das heißt du brauchst hier immer einen Python-Wrapper/Framework/... So wie du die Frage gestellt hast, würde ich sagen lame, libvorbis/libogg, libflac, ....
Mir ging es aber nicht um die Begrifflichkeit, sondern was du da nun genau suchst. Denn wenn pygame(kann man im übrigen auch partiell installieren) schon zu Groß ist, dann musst du solche Projekte, wie das von deets vorgeschlagene nehmen. Aber dann halt mit "PyAudio is still super-duper alpha quality" leben müssen.
Re: Schlanke Musik-Library
Verfasst: Montag 9. Mai 2011, 14:12
von Hyperion
Ich frage mich bei solchen Beiträgen immer, wie man "Größe" definiert? Ist damit der Verbrauch im RAM gemeint? Auf der Platte? Anzahl an Funktionen / Klassen?
Neben der Uneindeutigkeit des Kriteriums "Größe" käme nach einer genaueren Eingrenzung noch die Frage auf, inwiefern dieses Kriterium ein Problem darstellt. Ich habe da doch die Vermutung, dass oftmals auch dabei zu früh "optimiert" wird.