Logitech Squeezebox Touch

dito,
ich habe auch eine Synology.
Habe auch spaßeshalber alles eingerichtet, dass ich von unterwegs darauf zugreifen kann. Da ich aber meine Musik in lossless habe und die 212+ nicht brav genug ist um die Files "on the fly" zu transcodieren und die Upstream-Rate limitiert ist, war es nur so ein Versuch. Bei Dateien, bei der die Bitrate nicht allzu hoch ist, funktioniert es sogar. Bisher habe ich es aber nciht wirklich gebraucht, sonst hätte ich geschaut, dass ich NAS bekomme welche flink genug transkodieren kann, oder hätte meine Upstreamrate aufgebohrt. (Was nicht kostenlos vonstatten geht)

Ich habe jetzt mal testweise ein Album zu diesem Google-Dienst hochgeladen, dass ich auf meinem Rechner als FLAC abgelegt hatte. Um zu testen, ob Google gapless hinbekommt, habe ich mich für The Wall von Pink Floyd entschieden. Und natürlich baut mir Google beim Abspielen eine fette Pause zwischen die Tracks.
Kein Wunder: Der Google-Dienst schluckt die FLAC-Dateien zwar ohne Murren, was auf dem Server ankommt ist aber mit LAME enkodiertes MP3 mit 320 kbps. Die Tags werden dabei bereinigt (es ist nur noch das Wichtigste vorhanden) und das Coverbild von 600x600 auf 256x256 verkleinert.

Interessant, aber ein Anwendungsszenario fällt mir immer noch nicht ein.

Gapless ist eine Eigenschaft des Wiedergabegeräts bzw. -programms und hat nichts mit dem Format der Musikdateien zu tun, egal ob die in irgendeiner Cloud oder auf der heimischen Festplatte liegen. Wie gibst Du die Google-Musik denn mit der Squeezebox wieder?

Das stimmt nicht. Sowohl das Gerät als auch das Dateiformat muss Gapless unterstützen und mp3 tut das nicht, sondern baut grundsätzlich Pausen an Anfang und Ende ein. Es gibt Geräte, die gapless mit mp3 simulieren indem sie Crossfading verwenden, aber echtes gapless Playback ist das nicht.

Allerdings vermute ich auch, dass es hier nicht am Format sondern am Fehlen eines geeigneten Streamingprotokolls liegt, denn so ganz einfach ist das mit der Gapless-Wiedergabe beim Streamen nicht. In der Regel packen Streamingdienste dehalb, damit's nicht so auffällt, am Ende eines Tracks ein Fadeout 'dran. Spotify zum Beispiel musste deshalb ihre ganze Bibliothek neu codieren, als sie gapless Playback eingeführt haben.

Hier kommt noch dazu, wie Dienste wie Google Play funktionieren: Die speichern nicht für jeden seine eigenen Musikdaten, sondern erkennen, was Du da hochgeladen hast und wenn sie die schon in ihrer eigenen Bibliothek haben, dann bekommst Du einen Link darauf, nicht auf Deine eigenen Daten. Daher auch die geänderten Tags und Bilder. Und da kann sich dann schon die Version auch mal unterscheiden, die Du dann bekommst.
Macht ja alles nix, Musik ist Musik, nicht wahr. Spotify hatte ja auch mangels Rechten, hübsche, nachgesungene Versionen von Beatles-Songs in der Olympia-Playliste, das wird dann der nächste Schritt: Du bekommst das, wo die Rechte am billigsten waren

Sowohl die Squeezebox als auch iTunes (als auch sicherlich andere) können MP3-Alben gapless wiedergeben. Dabei nehmen sie kein Crossfading vor, was man ja an den Übergängen "erlauschen" würde. Mit ausreichend Speicher und dem richtigen Algorithmus sollte das auch nicht allzu schwer sein. Daher bleibe ich mal dabei, dass die Wiedergabeseite entscheidend ist.

Wu schrieb:

Wie gibst Du die Google-Musik denn mit der Squeezebox wieder?

Da habe ich noch nicht rausgefunden, wie das funktioniert. Bisher habe ich das nur mit dem von Google bereitgestellten Programm für den PC bzw. mit der App ausprobiert. Ich weiß auch gar nicht, ob es überhaupt schon andere Möglichkeiten gibt. Wäre natürlich interessant, ob die Touch beim Streamen von Google gapless (simulieren?) kann.

ein Anwendungsszenario fällt mir immer noch nicht ein

Mir ehrlich gesagt auch nicht. Mobil genutzt schränkt es die Bandbreite ein, und die Leute werden sich wundern, wie schnell die (Volumen-)Flat von 500MB aufgebraucht werden kann.

Sowohl die Squeezebox als auch iTunes (als auch sicherlich andere) können MP3-Alben gapless wiedergeben. Dabei nehmen sie kein Crossfading vor, was man ja an den Übergängen "erlauschen" würde. Mit ausreichend Speicher und dem richtigen Algorithmus sollte das auch nicht allzu schwer sein.

Sollte man meinen. Trotzdem scheitern angeblich renomierte Hersteller wie bspw. Marantz immer noch an Gapless, während das für z.B. die WAP-Player von TEAC kein Problem war.

Wu schrieb:

Sowohl die Squeezebox als auch iTunes (als auch sicherlich andere) können MP3-Alben gapless wiedergeben. Dabei nehmen sie kein Crossfading vor, was man ja an den Übergängen "erlauschen" würde.

Das ist nicht wahr. iTunes erstellt dafür extra eine Analysedatenbank (keine Anhung, ob sie die Daten direkt manipulieren, oder dann Crosfade machen), die Squeezebox MACHT Crossfade. Es ist sehr kurz, ca. 1/10s, aber es ist Crossfade. Erkennt man, wenn man selber mal einen Player dafür schreibt
Außerdem bleibt, wenn man genau hinhört auch sowohl bei iTunes als auch bei der Squeezebox eine, wenn auch sehr kurze, Pause zwischen den Tracks.

Viridarium schrieb:

Wu schrieb: Wie gibst Du die Google-Musik denn mit der Squeezebox wieder? Da habe ich noch nicht rausgefunden, wie das funktioniert. Bisher habe ich das nur mit dem von Google bereitgestellten Programm für den PC bzw. mit der App ausprobiert. Ich weiß auch gar nicht, ob es überhaupt schon andere Möglichkeiten gibt. Wäre natürlich interessant, ob die Touch beim Streamen von Google gapless (simulieren?) kann.

Google hat keine API dafür veröffentlicht, insofern ist es für Dritte derzeit nicht ohne weiteres möglich, das zu verwenden.
Ich habe in iPeng einen Workaround über den Browser, mit dem Du einzelne Tracks an die Squeezebox schicken kannst, da das aber nur mit einzelnen Tracks geht, kannst Du da Gapless nicht ausprobieren. Würde aber nicht funktionieren, denn der Squeezebox-Server (der das mit dem Gapless managed) baut den Crossfade zwischen den Tracks nur bei den Tracks eines Albums ein, d.h. er müsste wissen, dass das ein Album ist, das weiß er aber nur bei der eigenen Musiksammlung. Mit Onlinediensten geht das nur bei Formaten wie Ogg oder AAC, die explizit auch Gapless unterstützen.

coolio107 schrieb:

Außerdem bleibt, wenn man genau hinhört auch sowohl bei iTunes als auch bei der Squeezebox eine, wenn auch sehr kurze, Pause zwischen den Tracks.

Ich höre keine Pause, auch kein Knacksen, Klacken o.ä. Und ich habe bereits mehrmals genau hingehört. Ich sehe auch keinen Grund, weshalb eine Gapless-Implementation für MP3 unbedingt Crossfading benötigt.

Weil mp3 eine Pause einbaut. Man kann's auch nicht bei jedem Track hören, Knacken gibt es nicht, es ist eine richtige Pause. Man kann sie prima messen und auch sehen, in welcher Form sie gesendet wird.

Bei iTunes kann ich's nicht genau sagen, das verwende ich fast nie und ich habe da auch noch nie was gemessen, ich weiß nur, dass es mir da auch schon mal aufgefallen war.

coolio107 schrieb:

Weil mp3 eine Pause einbaut.

Und die Squeezebox blendet diese Pause wieder aus - ohne Crossfading.

Ich habe schon mehrfach bei Marillion - Misplaced Childhood hingehört, konnte aber bei der Wiedergabe über die Squeezebox zwischen den einzelnen Titeln beim besten Willen keine Störungen zwischen den Tracks heraushören. Wie auf dem Originalalbum gehen die einzelnen Tracks nahtlos ineinander über.

coolio107 schrieb:

Weil mp3 eine Pause einbaut. Man kann's auch nicht bei jedem Track hören, Knacken gibt es nicht, es ist eine richtige Pause. Man kann sie prima messen und auch sehen, in welcher Form sie gesendet wird. Bei iTunes kann ich's nicht genau sagen, das verwende ich fast nie und ich habe da auch noch nie was gemessen, ich weiß nur, dass es mir da auch schon mal aufgefallen war.

Also keine Ahnung obs was bringt, aber laut Wiki kann iTunes Gapless und auch die neueren Mp3 sollen Gapless können, Vorrausetzung ist das die Mp3 ATRAC haben.


Ob das alles so stimmt weiß ich nicht, ob euere Thema dadurch bereichert wird auch nicht, aber ich fand es interessant und wollte nur mal kurz Posten was ich zu den Thema gefunden habe.

http://de.wikipedia.org/wiki/Unterbrechungsfreie_Wiedergabe


@Stuhlfänger

stimmt wohl hab den Satzt falsch verstanden dachte der bezieht sich auf Mp3 dem ist aber nicht so

ATRAC hiess das Mini-Disk-Format, das hat mit .mp3 nichts zu tun.

Aus dem zitierten Wikipedia-Artikel:

Im Open-Source-Encoder LAME für das MP3-Format ist eine Funktion implementiert, die den erzeugten Dateien Informationen darüber hinzufügt, bis wohin die Datei Nutzdaten enthält. Geeignete Abspielgeräte oder -Software, beispielsweise foobar2000, VUPlayer oder mpg123, können unter Nutzung dieser Informationen die Fülldaten des letzten Datenblocks überspringen und so die Unterbrechungen weglassen.

Im Grunde ist das eine Krücke. Möglicherweise unterstützt die SBT das ja.

Stuhlfänger schrieb:

Im Grunde ist das eine Krücke.

Als eine Krücke sehe ich das nicht. Die Krücke sehe ich eher darin, daß diese Informationen nicht direkt in das MP3-Dateiformat eingeflossen sind und erst nachträglich definiert wurden. Deshalb hängt es von der jeweiligen Implementierung ab, ob sie verwendet werden.
Soweit ich weiß, ignoriert iTunes diese Tags und analysiert Anfang und Ende eines Tracks selbst. Funktioniert prinzipiell zwar auch, doch die Informationen, die bereits beim Kodieren vorhanden waren, sind halt präziser.

Drexl schrieb:

coolio107 schrieb: Weil mp3 eine Pause einbaut. Und die Squeezebox blendet diese Pause wieder aus - ohne Crossfading. Ich habe schon mehrfach bei Marillion - Misplaced Childhood hingehört, konnte aber bei der Wiedergabe über die Squeezebox zwischen den einzelnen Titeln beim besten Willen keine Störungen zwischen den Tracks heraushören. Wie auf dem Originalalbum gehen die einzelnen Tracks nahtlos ineinander über.

Probier' Cross von Justice, da hörst Du's. Auch auf der SB.

casper1981 schrieb:

Also keine Ahnung obs was bringt, aber laut Wiki kann iTunes Gapless und auch die neueren Mp3 sollen Gapless können, Vorrausetzung ist das die Mp3 ATRAC haben.

iTunes verwendet ja eigentlich AAC, nicht mp3. Was "neue" MP3s mit ATRAC sind, weiß ich nicht, ich kenne nur MP3s mit mp3.

coolio107 schrieb:

Probier' Cross von Justice, da hörst Du's. Auch auf der SB.

Hab' ich nicht. Aber wenn ich es bei Misplaced Childhood nicht höre, kann ich mir nicht vorstellen, daß es bei einer anderen Platte großartig anders wäre.

Vielleicht eher Deine SB-Einstellungen? Ich habe "Überblendung" und "Intelligente Überblendung" beides deaktiviert.

Stuhlfänger schrieb:

Aus dem zitierten Wikipedia-Artikel: Im Open-Source-Encoder LAME für das MP3-Format ist eine Funktion implementiert, die den erzeugten Dateien Informationen darüber hinzufügt, bis wohin die Datei Nutzdaten enthält. Geeignete Abspielgeräte oder -Software, beispielsweise foobar2000, VUPlayer oder mpg123, können unter Nutzung dieser Informationen die Fülldaten des letzten Datenblocks überspringen und so die Unterbrechungen weglassen.

Aha. Dann hängt's vielleicht von der Codierung ab.
So sollte das in der Tat gehen, sehe das auch nicht als Krücke, so läuft das nämlich bei FLAC, AAC, Ogg etc. auch.
Nur ist es halt nicht Teil des mp3-Standards, d.h. Du bist davon abhängig, was der Player und der Encoder kann und ob sie solche inoffiziellen Ergänzungen verstehen.

coolio107 schrieb:

So sollte das in der Tat gehen, sehe das auch nicht als Krücke, so läuft das nämlich bei FLAC, AAC, Ogg etc. auch. Nur ist es halt nicht Teil des mp3-Standards, d.h. Du bist davon abhängig, was der Player und der Encoder kann und ob sie solche inoffiziellen Ergänzungen verstehen.

Das meinte ich mit Krücke. Inzwischen dürften zwar die meisten .mp3s mit LAME erstellt werden bzw. worden sein, aber die wenigsten Hardware-Player unterstützen Gapless-Playback bei .mp3s.

coolio107 schrieb:

casper1981 schrieb: Also keine Ahnung obs was bringt, aber laut Wiki kann iTunes Gapless und auch die neueren Mp3 sollen Gapless können, Vorrausetzung ist das die Mp3 ATRAC haben. iTunes verwendet ja eigentlich AAC, nicht mp3. Was "neue" MP3s mit ATRAC sind, weiß ich nicht, ich kenne nur MP3s mit mp3.

Ah ok wusste ich bis jetzt auch noch nicht, das iTunes in AAC sind

ne Sorry, das mit dem ATRAC war von mir falsch verstanden, der Satz bezog sich jedoch nicht mehr auf Mp3, so wie ich es verstanden hatte sondern nur auf Gapless, welches von ATRAC unterstützt wird.

Hi !

ich habe leider ein Problem beim abspielen von Hörspielen über einen 32 Gb USB Stick .
Kurz nach Abspielbeginn kommt die Meldung "lokaler Musikdirektor wurde aufgrund eines Problems beendet."


Ein verbinden mit dem Stick ist danach nicht mehr möglich.

Nach dem Neustart müssen alle datein neudurchsucht werden.
Das geschieht nur bei einigen Dateien. Eigentlich normale mp3 mit 192 kbs.

Ich bediene über das iPad 3 und Drücke das Album etwas länger um alle Kapitel abzuspielen.
Ist das zuviel für den Server ?

Hat jemand eine Idee ?

Lg

Maik

Drexl schrieb:

coolio107 schrieb: Probier' Cross von Justice, da hörst Du's. Auch auf der SB. Hab' ich nicht. Aber wenn ich es bei Misplaced Childhood nicht höre, kann ich mir nicht vorstellen, daß es bei einer anderen Platte großartig anders wäre. Vielleicht eher Deine SB-Einstellungen? Ich habe "Überblendung" und "Intelligente Überblendung" beides deaktiviert.

Ja, wundert mich auch, was Coolio dazu meint. Aber selbst wenn es so wäre, meine Aussage war ja, dass eher der Abspieler das
Ergebnis bestimmt als das Format - und das hat er letzlich bestätigt ;-) Ob da dann noch ein unhörbarer Restgap oder Crossfade drin ist bei Formaten, die eigentlich nicht gapless-geeignet sind, ist mir eigentlich egal.

Beides auch aus bei mir.

Maikj schrieb:

Hat jemand eine Idee ?

Kannst Du die einzeln abspielen?
Das sollte nicht zu viel für den Server sein, ich hätte eher den Verdacht, dass er sich irgendwo am Dateiformat verschluckt, Audiobooks haben da teilweise etwas komische Formate.
Was für eine Bitrate ist das denn? Ich hab' irgendwo in Erinnerung, dass die SB Probleme mit weniger als 32kbit hat.

Das Gapless-Thema ist interessant. Ich habe geteste, das Abhören erfolgte per Kopfhörer.

Format: MP3 VBR V0 Lame
Album: Depeche Mode - Black Celebration
Test 1: Übergang Black Celebration - Fly On The Windscreen
Test 2: Übergang Fly On The Windscreen - A Question Of Lust

Auf der SB Classic erfolgte der Übergang nahtlos, jedenfalls habe ich nichts wahrgenommen. Hingegen gab es beim Abspiele via iPeng, iPeng HD und Squeezepad jeweils einen deutlichen Aussetzer.

Das liegt daran, dass die alle drei kein Crossfade unterstützen.
Daher weiß ich ja, dass die SB das technisch über ein Crossfade umsetzt.
Allerdings kommt beim iPod/iPhone/iPad (wohl auch bei Android) noch ein anderer Aspekt dazu, nämlich, dass man da keine volle Kontrolle über die Arbeitsweise des mp3-Decoders hat, sondern den des Systems nutzen muss. Das ist bei FLAC und OGG anders.

Nun, dann scheint das Crossfading im Sinne von Gapless prima zu funktionieren. Aus- bzw eingeblendet wird hörbar nichts.

FLAC unterstützt Gapless also direkt, somit auch bei der Wiedergabe mit den genannten Programmen?

Interessant mit dem gapless und MP3. Dass Problem war mir vorher gar nicht so bewusst. Ich habe mal eine Flac-Datei von mir in MP3 umgewandelt. Tatsächlich ist die MP3-Datei 0,05 Sekunden länger. Man sieht das auch ganz deutlich, wenn man beide Dateien in audacity lädt und zoomt. Wenn die MP3-Datei zu lang ist, ist es ja tatsächlich nicht ganz einfach mit dem gapless.

Mal ein anderes Thema: Soweit ich es verstanden habe, unterstützt die SBT pro Server immer noch nur eine einzige Datenbank, d.h. es ist nicht möglich, verschiedene Biliotheken auszuwählen. Und es sieht auch nicht so aus, daß Logitech in der Richtung noch was reissen wird. Als Lösung wird das "Multi Library Plugin" genannt, wobei das wohl nicht ganz trivial in der Anwendung ist. Hat da jemand Erfahrungen mit? Wird das von iPeng unterstützt?

coolio107 schrieb:

Daher weiß ich ja, dass die SB das technisch über ein Crossfade umsetzt.

Das glaube ich immer noch nicht. Denn Crossfading würde ja bedeuten, daß während des Übergangs von zwei Tracks kurzzeitig die Lautstärke abnimmt. Das konnte ich bisher noch nicht feststellen.

Mit den passenden Metainformationen weiß die Squeezebox, bis zu welchem Sample er Track 1 abspielen muß und ab welchem Sample Track 2 beginnt. Damit sind nahtlose Übergänge ohne Crossfading möglich.

Viridarium schrieb:

Wenn die MP3-Datei zu lang ist, ist es ja tatsächlich nicht ganz einfach mit dem gapless.

Aus diesem Grund schreibt LAME in einen Info-Tag die nötigen Metainformationen zum Gapless-Playback (wie viele Samples am Anfang und am Ende des Stückes übersprungen werden müssen).

Die genaue Definition des Info-Tags findet sich hier. Im Detail: Bytes 0xb1-0xb3

Dentaku schrieb:

Nun, dann scheint das Crossfading im Sinne von Gapless prima zu funktionieren. Aus- bzw eingeblendet wird hörbar nichts. FLAC unterstützt Gapless also direkt, somit auch bei der Wiedergabe mit den genannten Programmen?

Ja. Wobei ich über SqueezePad da nichts definitiv sagen kann, ich glaube aber schon. Für iPeng: ja, zumindest die aktuellen Versionen bzw. die aus dem letzten halben Jahr, wenn sie mindestens auf einem iPad oder iPhone 3GS oder iTouch 3rd gen laufen.

Die Pause bei mp3 kann auch sehr kurz sein (deutlich unter 1/100s), aber sie ist so gut wie immer da.

Drexl schrieb:

coolio107 schrieb: Daher weiß ich ja, dass die SB das technisch über ein Crossfade umsetzt. Das glaube ich immer noch nicht. Denn Crossfading würde ja bedeuten, daß während des Übergangs von zwei Tracks kurzzeitig die Lautstärke abnimmt. Das konnte ich bisher noch nicht feststellen.

Aha. das kannst Du also für 20ms feststellen? Da hast Du aber tolle Ohren.
In erster Linie bedeutet es übrigens, dass für eine bestimmte Zeit BEIDE Tracks abgespielt werden, das mit der Lautstärke ist nur ein Effekt, damit es nicht in Summe lauter wird.

Mit den passenden Metainformationen weiß die Squeezebox, bis zu welchem Sample er Track 1 abspielen muß und ab welchem Sample Track 2 beginnt. Damit sind nahtlose Übergänge ohne Crossfading möglich.

Die Box weiß erstmal gar nix, nur der Server weiß und schickt der Box die Daten und der Server schickt bei mp3 ein Crossfade-Kommando und eine Dauer, wenn auch sehr kurz.
Das Problem bei mp3 ist, dass Du, abhängig vom Codec, eben nicht immer Zugriff auf jedes Sample hast. In iPeng z.B. haben wir immer nur einen Stream gleichzeitig, wir müssten ein komplett anderes Wiedergabeverfahren unter iOS verwenden, um die beinden Streams parallel verwenden zu können und dann würde vermutlich die USB-Audio-Wiedergabe scheitern, hat sie jedenfalls bei unseren Versuchen getan.

Verdammt, ich haben einen Squeezebox-Player (mit-)GESCHRIEBEN und locker 1.000h mit dem Testen von genau dem Scheiß zugebracht. Ich kann Dir gerne ein paar hundert Seiten Logfiles dazu schicken, wie die Squeezebox "gapless"-MP3s behandelt. Ich WEISS, was die Dinger tun, ich rate hier nicht 'rum wie Du.

Stuhlfänger schrieb:

Mal ein anderes Thema: Soweit ich es verstanden habe, unterstützt die SBT pro Server immer noch nur eine einzige Datenbank, d.h. es ist nicht möglich, verschiedene Biliotheken auszuwählen. Und es sieht auch nicht so aus, daß Logitech in der Richtung noch was reissen wird.

Naja, beim UE Smart Radio kannst Du zumindest zwei Bibliotheken von zwei Rechnern parallel verwenden (also z.B. Tracks von beiden nacheinander abspielen).

Als Lösung wird das "Multi Library Plugin" genannt, wobei das wohl nicht ganz trivial in der Anwendung ist. Hat da jemand Erfahrungen mit? Wird das von iPeng unterstützt?

Nein. In iPeng kannst Du nicht die "normalen" Hauptmenüs ausblenden.
MultiLibrary unterdrückt ja die "vollständigen" Menüs und erstellt dann mit Hilfe von CustomBrowse neue. Die neuen tauchen in iPeng auf, die alten aber auch.

Das wäre mir eine zu große Änderung und würde vieles komplizieren, das lohnt nicht für die 5 Leute, die es geschafft haben, das Setup erfolgreich aufzubauen.

coolio107 schrieb:

In erster Linie bedeutet es übrigens, dass für eine bestimmte Zeit BEIDE Tracks abgespielt werden, das mit der Lautstärke ist nur ein Effekt, damit es nicht in Summe lauter wird.

Woher willst Du willen, wie es die internen MP3-Decoder der Squeezebox (in meinem Fall Receiver und Boom) machen? Gapless ist wie gesagt ein Player-Feature, d.h. der Player, der MP3 dekodiert, muß den Info-Tag auswerten. Im Falle des Receivers und der Boom sitzt der MP3-Decoder im Gerät, der Squeezeserver selbst liefert nur den MP3-Datenstrom, dekodiert wird im Abspielgerät.

Drexl schrieb:

Woher willst Du willen, wie es die internen MP3-Decoder der Squeezebox (in meinem Fall Receiver und Boom) machen? Gapless ist wie gesagt ein Player-Feature, d.h. der Player, der MP3 dekodiert, muß den Info-Tag auswerten. Im Falle des Receivers und der Boom sitzt der MP3-Decoder im Gerät, der Squeezeserver selbst liefert nur den MP3-Datenstrom, dekodiert wird im Abspielgerät.

Herrgott lies, was ich schreibe.
Bei den Squeezeboxen wertet der Player NICHTS aus. Insbesondere die alten (Boom, Classic) sind da komplette Thin Clients. Die bekommen vom Server bis auf den letzten Frame gesagt, was sie machen sollen. Gapless Playback ist bei der Squeezebox KEIN Player-Feature, sondern ein Server-Feature.
Bei Internetradio strippen sie sogar die Metainformationen aus dem Stream und schicken die zum Server, damit der sie verarbeitet, selber machen die da nix,

MP3 decodieren machen sie selber, Tags auswerten und die Wiedergabe steuern nicht. Der Server gibt die Steuerungsinformationen, wenn der nicht sagt, dass die Box einen Frame überspringen soll, macht die das auch nicht.
Ansonsten würden so hübsche Dinge wie Synchronisation gar nicht funktionieren.

Du hast Null Ahnung, wie die Squeezebox funktioniert, gibst aber hier den Besserwisser.

coolio107 schrieb:

das lohnt nicht für die 5 Leute, die es geschafft haben, das Setup erfolgreich aufzubauen.

Alles klar, das dachte ich mir.

coolio107 schrieb:

Bei den Squeezeboxen wertet der Player NICHTS aus. Insbesondere die alten (Boom, Classic) sind da komplette Thin Clients.

Nein, die Player können MP3 direkt dekodieren. Daher ist MP3-Gapless auch ein Feature der Firmware der Clients (Squeezebox 2/3, Receiver, Boom, Transporter, etc.)
Implementiert wurde MP3-Gapless im Oktober 2006.

Wenn der Client eine Tonformat nicht selbst dekodieren kann, wird es vom Squeezeserver transkodiert, aber selbst eine Boom kann selbst MP3 dekodieren und auch selbst den MP3-Gapless-Header auswerten.

Mal was anderes: Ich habe vorgestern ca. 150 GB Musik auf meinen QNAP Server gepackt (hat 9 h gedauert), seit dem ist die CPU Auslastung des Servers bei 100% und die SB kann nicht auf die Daten zugreifen. Ist das normal, soll ich den Server noch arbeiten lassen, oder?

Drexl schrieb:

Wenn der Client eine Tonformat nicht selbst dekodieren kann, wird es vom Squeezeserver transkodiert, aber selbst eine Boom kann selbst MP3 dekodieren und auch selbst den MP3-Gapless-Header auswerten.

Selbst Decodieren kann sie, ja, das habe ich auch geschrieben. Lies', was ich geschrieben habe, bevor Du antwortest. Es geht nicht um Transcodieren, es geht um die Steuerung des Streams, das ist etwas anderes.
Ach ja: und lies Deinen eigenen Link, da steht nämlich letztlich genau das, was ich auch geschrieben habe.

So, und jetzt bin ich hier 'raus. Du weißt es ja eh besser und sonst gar nichts.

andreaspw schrieb:

Mal was anderes: Ich habe vorgestern ca. 150 GB Musik auf meinen QNAP Server gepackt (hat 9 h gedauert), seit dem ist die CPU Auslastung des Servers bei 100% und die SB kann nicht auf die Daten zugreifen. Ist das normal, soll ich den Server noch arbeiten lassen, oder?

Kannst Du das Web Interfeace erreichen? Wenn ja: kannst Du mal unter Einstellungen->Informationen schauen, was der Scanner so treibt?

Also im QNAP Haupmenue zeigt der Recourcenmonitor an, dass "mymediadplayer" 62,5% CPU Auslastung verursacht. Hast Du das gemeint?

ich frage mich gerade, was mymediadbserver (nicht player, wie gerade geschrieben, sorry) überhaupt ist...

klingt nicht nach Squeezebox.
Ich habe das Web-Interface des Logitech-Servers gemeint:
http://<Adresse Deines QNap>:9001
vermutlich

Hab gerade mal im QNAP Forum geschaut, es scheint auch an der neuen Firmware zu liegen, dass der Server mit dem Prozess so lange läuft. Ma empfiehlt abzuwarten und dem Server Zeit zu geben. Ich habe dann gleichzeitig diese große Datenmenge geladen, jetzt warte ich mal bis morgen.

Danke!

coolio107 schrieb:

elbst Decodieren kann sie, ja, das habe ich auch geschrieben. Lies', was ich geschrieben habe, bevor Du antwortest.

Dann lies Du auch alles, was ich geschrieben habe. Ich habe einen Link zur Bug-Datenbank hinzugefügt.

Dort heißt es:

Slimdevices Bug-DB schrieb:

This bug is fixed in firmware sb65/tr19.

d.h. Squeezebox 2/3 Firmware (sb65) bzw. Transporter Firmware (tr19), also Firmware-Feature, nicht Squeezeserver-Feature.
Wobei die Server-Software auch dafür sorgen muß, daß der Gapless-Header nicht verworfen wird (also auch ein bißchen Squeezeserver-Feature). Dazu findet man in Quellcode des Squeezeservers im entsprechenden Source-File (Slim/Formats/MP3.pm) einen Hinweis:


# Read the initial audio frame, this supports seeking while preserving
# the Xing header needed for gapless playback

d.h. der Squeezeserver stellt sicher, daß die Gapless-Informationen nicht versehentlich verworfen werden.

Drexl schrieb:

Dann lies Du auch alles, was ich geschrieben habe. Ich habe einen Link zur Bug-Datenbank hinzugefügt.

Und ich mich in meiner Antwort darauf bezogen.

# Read the initial audio frame, this supports seeking while preserving # the Xing header needed for gapless playback d.h. der Squeezeserver stellt sicher, daß die Gapless-Informationen nicht versehentlich verworfen werden.

Nö. Er stellt sicher, dass sie beim Seek innerhalb eines Tracks berücksichtigt werden. Wenn Du schon aus dem Code zitierst, solltest Du verstehen, was der jeweilige Code tut. Dieser hier sorgt dafür, dass, wenn Du zu Sekunde 7 springen willst und im Header der MP3-Datei 2s zu überspringende Pause angegeben sind (übertrieben, in der Realität sind die Werte meist deutlich unter 1s und die Maßeinheit hier sind Frames, nicht Sekunden), dass Du dann nicht bei Sekunde 5 landest. Die Funktion liefert dann den Frame ab Sekunde 7. Vermutlich zum Streamen

read $localFh, my $buffer, $second_frame - $track->audio_offset;

So. Jetzt ist wirklich Schluss.

coolio107 schrieb:

Wenn Du schon aus dem Code zitierst, solltest Du verstehen, was der jeweilige Code tut.

Dito.

Dieser hier sorgt dafür, dass, wenn Du zu Sekunde 7 springen willst und im Header der MP3-Datei 2s zu überspringende Pause angegeben sind (übertrieben, in der Realität sind die Werte meist deutlich unter 1s und die Maßeinheit hier sind Frames, nicht Sekunden), dass Du dann nicht bei Sekunde 5 landest. Die Funktion liefert dann den Frame ab Sekunde 7.

Eben nicht. Wenn Du schon Code zitierst, solltest Du auch verstehen, was der Code tut.

        my $offset = $track->audio_offset + 1;
        my $second_frame = Audio::Scan->find_frame_fh( mp3 => $localFh, -$offset ) ;

Hier wird der nächste Frame ab einem gegebenen Offset gesucht.

        seek $localFh, $track->audio_offset, 0;

Hier wird wieder zum Anfang des Audiofiles (mögliche Header werden übersprungen) gesprungen. Wie auch oben wird immer relativ zu $track->audio_offset gesprungen.
        read $localFh, my $buffer, $second_frame - $track->audio_offset;

Und hier wird der erste Frame bis hin zum gerade oben gelesenen Frame eingelesen. Ohne den Intial-Frame fehlen dem Clients nach einem Seek die nötigen Informationen zum Gapless-Playback.