[ANNOUNCE] muggle 0.1.7

Zitat

Original von wolfgang61

besserer Vorschlag, der GiantDisc - kompatibel bleibt?

Bisher nicht, aber ich denke da jetzt nochmal in Ruhe drüber nach. Wenn da heute noch was Sinnvolles rauskommt, geb' ich bescheid. Einstweilen find ich deine Lösung - für mich - wie gesagt tauglich.

Zitat

auf Version 0.1.8 warten, kommt evtl demnächst. Siehe mein Beitrag von heute morgen 04:27 Board time. Hoppla - die stimmt ja wieder!

Okay, denn ich hätte sonst noch so viele Fragen: Wenn eine Liste ('spielen') erstmal Inhalte hat, aber nicht mehr spielt - wie kann ich sie nochmal starten? Warum hängst du bis 04.27h im Forum rum und hast am nächsten Tag um 10 schon wieder nix Wichtigeres zu tun? Wie kann ich Euch nur davon überzeugen, dass das .mpc-Format ein wichtiges Audiokompressionsformat mit Zukunft ist und ein totales Killerfeature darstellt?

danke: jeremia

Zitat

Original von jeremiaOkay, denn ich hätte sonst noch so viele Fragen: Wenn eine Liste ('spielen') erstmal Inhalte hat, aber nicht mehr spielt - wie kann ich sie nochmal starten?

mit "sofort spielen" auf der Sammlung "spielen" - das fängt allerdings wieder ganz vorne an.

Zitat

Warum hängst du bis 04.27h im Forum rum und hast am nächsten Tag um 10 schon wieder nix Wichtigeres zu tun?

Heuschnupfen. Wenn ich damit aufwache, ist es aus mit Schlafen.

Zitat

Wie kann ich Euch nur davon überzeugen, dass das .mpc-Format ein wichtiges Audiokompressionsformat mit Zukunft ist und ein totales Killerfeature darstellt?

Zitat

Schon überzeugt - Patches werden akzeptiert.

Im Ernst: Decoder macht Lars.

Yippie!

Ja, Lars, das gibt's. Ich mach mich schnell schlau...

jeremia

Also:

Homepage: www.musepack.net

Debian-library: libmusepack2 (läuft bei mir für xmms-musepack, abcde und bmp-musepack)

# apt-cache search musepack
abcde - A Better CD Encoder
quodlibet - audio library manager and player for GTK+
bmp-musepack - beep media player (xmms2/bmp) decoder plugin for musepack
bmp-plugins-musepack - extra plugins for beep media player - musepack
libmusepack-dev - decoder library for the musepack lossy audio codec - dev
libmusepack1 - decoder library for the musepack lossy audio codec - lib
libmusepack2 - decoder library for the musepack lossy audio codec - lib
mpcinfo - a simple command line mpc querying tool
musepack-decoder - high quality lossy audio codec (alpha) - decoder
musepack-encoder - high quality lossy audio codec - encoder
musepack-encoder-presv8 - high quality lossy audio codec (alpha) - encoder
musepack-replaygain - audio volume manipulation utility - musepack variant
xmms-musepack - xmms decoder plugin for musepack
easytag - viewing, editing and writing ID3 tags
akode - akode arts plugin

Bei musepack (=.mpc) gibt's dieses ReplayGain, d.h. falls der Encoderer nicht zu doof war, werden schon beim Encodinging Average Gain und Peak bestimmt. Mit Hilfe dieser Angaben kann beim Abspielen die Lautstärke nachgeregelt werden, ohne komprimieren zu müssen.

jeremia

Lars: ist es 'viel' aufwand eine passende decoder-klasse für muggle zu schreiben?

es ist natürlich schwierig sowas anzugeben; aber nur so im groben; denkst du ein C++ anfänger bekommt sowas mit blick auf die doku in vernünftiger zeit hin?

Zitat

muggle legt dann, wenn es einen Namen noch nicht kennt, einen neuen Genre - Eintrag an mit einem noch unbenutzten GiantDisc - Kenner zaa (dann aufsteigend bis zzz). Und es gibt ein GiantDisc-Genre z namens "Eigene Genres", dann kommt das auch in der Genrehierarchie.

Hört sich das so sinnvoll an?

Je mehr ich darüber nachdenke, desto sinnvoller finde ich das. Da ich ja dann später die Kennungen zaa-zzz in der Genres-Tabelle wiederum in die Hierarchie einmodeln kann (indem ich diese Buchstabenkombinationen ändere), habe ich ja dann meine Custom-Made-Genre-Tabelle. Ja, das ist genau richtig so.

Allerdings fänd' ich's schon nicht schlecht, generell auch ID3v2-Tags bei Artist, Title und Album auszuwerten, so ihr das nicht schon macht (hatte aber heute nicht den Eindruck...). Ich bin so bekloppt, bei mir stehen da häufiger mal mehr als 30 Zeichen drin (ID3v1-Limit, soweit ich weiss).

Zitat

Original von wolfgang61

mit "sofort spielen" auf der Sammlung "spielen" - das fängt allerdings wieder ganz vorne an.

Okay, aber dann heisst 'sofort spielen' in diesem Zusammenhang eben gerade nicht sofort spielen, denn die tracks landen ja nicht in der top-priority-queue 'sofort spielen', sondern statt dessen wird die eliminiert und auf die lower-priority-queue 'spiele playliste xy' umgeschaltet - ich hoffe, ich verstehe das alles richtig? Denn während des Abspielens von 'sofort spielen' taucht im OSD nach grüner Taste der jeweilige Listeneintrag auf, den man veranlasst hatte, sofort zu spielen, aber im Falle einer Sammlugns-Spielung steht da ja der Name der Sammlung?
Also, kleiner Vorschlag am Rande: Wie wär's denn, die Standardplayliste (pardon, Sammlung) nicht ausgerechnet 'spielen' zu nennen, sondern z.B. 'Standardsammlung'? Dann würde ich auch noch aus dem o.a. 'sofort spielen' in der Sammlungsliste z.B. ein 'spiele Sammlung' machen. Ich meine, euer muggle ist so geil, da muss man den Leuten auch ne Chance einräumen, das irgendwie zu schnallern...

Und dann noch ne Kleinigkeit: In der Tracklist einer Sammlung während des Abspielens steht:
Title (tabulator) Artist

Kann man daraus nicht
Title (tabulator) Artist (Album)

machen? Wenn's zu lang wird, wird's halt zu lang, und man sieht es nicht, aber häufig genug ist da noch viel Platz zumindest für die ersten paar Buchstaben des Albumnamens.

Und jetzt bin ich auch echt fertig für heute.

jeremia

Zitat

Original von jeremia
Allerdings fänd' ich's schon nicht schlecht, generell auch ID3v2-Tags bei Artist, Title und Album auszuwerten, so ihr das nicht schon macht (hatte aber heute nicht den Eindruck...). Ich bin so bekloppt, bei mir stehen da häufiger mal mehr als 30 Zeichen drin (ID3v1-Limit, soweit ich weiss).

muss ich mir ansehen. Ich hätte gedacht, libtag macht das transparent, aber ich weiss nicht, ob es v1 oder v2 den Vorzug gibt

Zitat

während des Abspielens von 'sofort spielen' taucht im OSD nach grüner Taste der jeweilige Listeneintrag auf, den man veranlasst hatte, sofort zu spielen, aber im Falle einer Sammlugns-Spielung steht da ja der Name der Sammlung?

das habe ich heute geändert, es steht da nun immer der Name des aktuellen Stückes

Zitat

Title (tabulator) Artist

Kann man daraus nicht
Title (tabulator) Artist (Album)

machen? Wenn's zu lang wird, wird's halt zu lang

bei mir ist oft schon der Titel alleine oder Album alleine zu lang (vor allem bei klassischer Musik)

Zitat

Originally posted by LarsAC
Wenn Du Dich daran wagen möchtest stehe ich aber gern mit Rat und Tat zur Seite. Mutige vor!

mmh. also ich hab mir mal die files vdr_decoder_[mp3|ogg|flac].[c|h] angesehen.
ich hab auch mal mit doxygen ein wenig doku generiert. sieht schonmal ganz gut aus.

muss ich für ein anderes format 'nur' eine klasse vom typ mgDecoder implementieren? [sorry wenn ich so blöd frage, aber ich stehe mit OO-Programmierung noch ein wenig auf kriegsfuss]

wo ist die struktur mad_pcm definiert? kommt das von der libmad? also da in den headern nachsehen?
wozu taucht das ganze "lock();" und "unlock();"? ich hab da was in vdr_decoder.c gefunden, aber das ganze locklock und co. verwirrt mich ncoh mehr.

P.S. du merkst mit sicherheit gerade, das ich nicht wirklich ahung von c++ habe. ich werde mich trotzdem mal versuchen; mehr als was neues lernen kann ich ja nicht.

Zitat

Original von jeremia
Je mehr ich darüber nachdenke, desto sinnvoller finde ich das. Da ich ja dann später die Kennungen zaa-zzz in der Genres-Tabelle wiederum in die Hierarchie einmodeln kann (indem ich diese Buchstabenkombinationen ändere), habe ich ja dann meine Custom-Made-Genre-Tabelle.

und nach dem Ändern neu importieren. Das Datenbankschema von GiantDisc kennt keine cascading updates, es verwendet noch nicht mal foreign keys. Wenn Du also Kennung zaa in der Genre-Tabelle änderst, bleibt der Wert zaa in den einzelnen Track unverändert.

Ja, genauso. Ich importiere sowieso ständig alles neu. Also für mich ist das wie gesagt wunderbar so.

jeremia

Hat eigentlich wer GiantDisc und muggle gleichzeitig laufen und auf die gleiche DB zugreifend?

Ich überlege nämlich ob ich GiantDisc parallel installiere um meine WLAN Karte meines Clies auch mal wieder zu nutzen

Mal ne andere Frage für die nächste Version von Muggle:
Hier in diesem Thread <Link> schreibt Cooper berechtigterweise, dass Plugins beim Aufruf keine Parameter benötigen. Man kann alles per Setup-Einstellungen im OSD des VDRs vornehmen. Habt ihr vor euch in der nächsten Version daran zu halten? Das käme der Vereinheitlichung und der einfacheren Integration in LinVDR etc. zugute.
Gruß
Jarny