Napster 5

[LocalHolgi]

Hi,

 

ich bin seit laanger Zeit ein Napster Nutzer und habe mir ein stattliches Archiv zusammengebaut. Davon abgesehen das die Daten DRM geschützt waren und die meisten nicht konvertieren musste, da mein MP3 Player damit klarkam. Nunja bis heute - seit gestern gibt es ja diese neue Rhapsody Variante von Napster und meine alten Songs gehen irgendwie nicht mehr. Die neue Version gefällt mir zwar optisch, aber inhaltlich werde ich nicht schlau. Wo zum Geier speichert das Teil meine geladenen Songs?

 

Ich weiß das ist Offtopic, aber vielleicht weiß ja jemand was

 

Holger

[hackbart]

Viel mehr als das was bei Heise stand, weiß ich auch nicht. Wenn es Dir hilft, die Songs werden im AppData Verzeichnis (unter Users\<User\Appdata\Roaming\com.Rhapsody.Napster5\Local Store) gespeichert. Deine geladenen Alben sind dann in dem Unteraccount (eMailadresse bei Napster) gespeichert. Die Verweise dazu stehen in der SQLite Datenbank die auch im Local Store Pfad zu finden ist.

 

Das positive ist das die Streams unverschlüsselt als AAC Plus Raw gespeichert sind. Negativ ist das du die ohne Konvertierung wohl nicht abspielen kannst. Man könnte einen Umwandler schreiben, da die Audioinfos in der Datenbank hinterlegt sind.

 

Was mir aber gar nicht gefällt ist, dass die Auswahl an Hörbüchern und Nicht-Mainstream Künstlern arg bescheiden ist. Such mal nach Rolf Zuckowski (ja ich weiß), dann siehste was ich meine. Optimistisch wie ich bin, würde ich sagen das da sicherlich die Bestände noch aufgebaut/konvertiert werden.

 

Christian

[LocalHolgi]

Cool - wenn es so ein Tool gäbe, würde ich sogar Geld ausgeben. Danke für den Tip mit der SQLite Datenbank. Ich hab mir mal meine Lokale hier angeguckt und die geladenen Alben waren da aufgelistet.

 

Holger

[edegl]

...das runtergeladene AAC File (kein Stream) überall wird problemlos abgespielt, kann mit mp3tag getaggt und natürlich auch konvertiert werden, z.B. in mp3. Das mache ich mit dbpoweramp.

 

 

Aber: das AAC mp4 File scheint von seinem Dateinamen völlig losgelöst, eine Zuordnung gelingt mir nur über den Zeitstempel und die annähernd gleiche Dateigröße.

.

Wie kann ich denn die sqlite Files für mich besser nutzbar machen? In einem einem Editor sehe ich nur den Wust von Text 'am Stück'.

 

Ede

[hackbart]

Naja, die Napster Anwendung lädt scheinbar M4A Dateien von deren Server, die wiederrum temporär im IE Cache gespeichert werden. Das ist sicher nur ein Seiteneffekt bei den meisten Nutzern unter Windows. Die Zieldaten werden dann in oben genannten Napster-Verzeichnis hinterlegt. Einmal eine kurze FLV Datei und einmal der eigentliche Song.

 

Die Songnamen sind in der SQLite Datenbank gespeichert, ebenso wie die Interpreten. Mit http://sqliteadmin.orbmu2k.de/ kann man sich z.B. die Datenbank angucken.

 

Christian

 

 

[dbraner]

Das positive ist das die Streams unverschlüsselt als AAC Plus Raw gespeichert sind. Negativ ist das du die ohne Konvertierung wohl nicht abspielen kannst. Man könnte einen Umwandler schreiben, da die Audioinfos in der Datenbank hinterlegt sind.

 

Wo sind die AAC Plus Raws unverschlüsselt gespeichert? In der Datenbank oder meinst Du die Dateien im IE-Cache?

 

Die IE-Cache Dateien könnte man mit iTunes matchen und sich dann die 256 KBit AAC von iTunes laden. Dazu müssten die Dateien im IE-Cache aber mindestens 96 KBit/s haben, wenn ich die iTunes-Match Regeln richtig verstanden habe.

 

BTW: Die NAPSTER 5.0 Software ist das übelste, was mir seit langem untergekommen ist.

[hackbart]

Nun Songs liegen im Local Store\eMail_Adresse\AlbumNr. Die Nummer kriegt man über die albumID in der Datenbank raus. Ein Song besteht aus einer FLV und einer weiteren Datei und hat stehts den gleichen Aufbau:

 

trackID_bitrate_05_rienf bzw. seed.flv. Der eigentliche Track ist in der _rienf Datei, der Container ist wohl eine Eigenentwicklung. Verschlüsselt scheint die Datei aber nicht wirklich zu sein.

 

Was relativ leicht geht ist aus den Infos der FLV Datei die im Browser Cache liegende M4A zu finden und diese mit den Daten aus der Datenbank korrekt zu benennen und zu sichern. Genügend Interesse vorausgesetzt und unter Berücksichtigung möglicher rechtlicher Aspekte kann man da sicher mehr draus machen, aber so lange das was ich sonst so gehört habe nicht mehr angeboten wird, werde ich nicht viel Arbeit investieren.

 

Christian

PS: Viel schlechter als die alte Napsterapplikation finde ich die Neue nicht. Wenngleich es mir widerstrebt eine Flashdatei als Anwendung anzusehen

[hackbart]

Also okay - ich bin ein ganzes Stück weitergekommen. Wenn man nur die funktionierenden Pakete mit Audio und VideoTag (8,9) liest und abspeichert klappts. Ich weiß nicht wirklich wie groß die "Garbage"-Pakete in der rief-Datei sind, aber wenn man ab einem "defekten" Paket einfach Byteweise so lange weiterliest bis mindestens 2 aufeinanderfolgende korrekte Pakete kommen (Reserved-DWord sollte da stets 0 sein) spielen die reparierten Songs nahezu fehlerfrei ab. Nahezu weil meine zurechtgezimmerte Testanwendung wohl doch einige Bugs hat.

 

Christian

 

PS: http://osflash.org/flv

 

 

 

 

 

[dbraner]

Also okay - ich bin ein ganzes Stück weitergekommen. Wenn man nur die funktionierenden Pakete mit Audio und VideoTag (8,9) liest und abspeichert klappts. Ich weiß nicht wirklich wie groß die "Garbage"-Pakete in der rief-Datei sind, aber wenn man ab einem "defekten" Paket einfach Byteweise so lange weiterliest bis mindestens 2 aufeinanderfolgende korrekte Pakete kommen (Reserved-DWord sollte da stets 0 sein) spielen die reparierten Songs nahezu fehlerfrei ab. Nahezu weil meine zurechtgezimmerte Testanwendung wohl doch einige Bugs hat.

 

Christian

 

PS: http://osflash.org/flv

 

Also ist das rienf File nichts anderes als ein nicht korrekt formatiertes FLV/MP4 File, richtig? D.h. ein Programm könnte nach korrekten FLV Tags suchen.

 

Was meinst Du mit reserved DWORD? Habe ich in der FLV-Formatbeschreibung nirgends gefunden.

[hackbart]

Naja gut ich mache im Endeffekt folgendes:

 

type
TFLVTag = record
     PreviousTagSize: DWord;
     TagType: Byte;
     DataSize: DWord;
     TimeStamp: DWord;
     TimeStampExtended: Byte;
     streamId: DWord;
//reserved = TimeStampExtended+streamId
   end;

TDataPacket = record
	Data: Pointer;
	Size: integer;
 end;


...

function TFLVConverter.ReadPacket(const Stream: TFileStream; out Data: TDataPacket): Boolean;
var
  pos: int64;
   Tag: TFLVTag; 
begin
  pos := Stream.Position;
  result := false;
  fillchar(data, sizeof(data), 0);

   if Stream.size - Stream.Position < 15 then exit;

  Tag.PreviousTagSize := Read32Bit(Stream);
  Stream.Read(Tag.TagType, 1);
  Tag.DataSize := Read24Bit(Stream);
  Tag.TimeStamp := Read24Bit(Stream);
  Stream.read(Tag.TimeStampExtended, 1);
  Tag.streamId := Read24Bit(Stream);

   result := (tag.TagType in [8, 9, $12]) and
     (Stream.position + tag.DataSize <= Stream.Size);

 if result then
   begin
  	data.Size := (stream.Position - pos) + tag.DataSize;
  	getmem(data.data, data.Size);
  	Stream.Position := pos;
  	Stream.read(data.Data^, data.Size);
  	result := true;
  end else
  	Stream.Position := pos + 1; //skip only one byte
end;

 

So genau ist das sicherlich nicht, aber zum Lesen der 15 Byte Header und der dazugehörigen Daten reicht das. In allen Dateien die ich getestet habe waren aber immer 5 größere Pakete "Müll". Dieser Müll ist sicherlich kein Müll, denn bei der Wiedergabe fehlen einzelne Fragmente.

 

Christian

[dbraner]

 

So genau ist das sicherlich nicht, aber zum Lesen der 15 Byte Header und der dazugehörigen Daten reicht das. In allen Dateien die ich getestet habe waren aber immer 5 größere Pakete "Müll". Dieser Müll ist sicherlich kein Müll, denn bei der Wiedergabe fehlen einzelne Fragmente.

 

Christian

 

ich glaube das Problem ist das überlesen der defekten Fragmente. Ich habe jetzt mal folgenden Ansatz verfolgt:

 

Ich habe die letzten 4 byte der seed Datei in der rienf Datei gesucht. Dabei habe ich festgestellt, dass es zwischen seed und rienf Datei ein Offset von 48 Byte gibt. Ich habe also zunächst die seed Datei in eine neue Datei kopiert und daran dann das große rienf File ab der Position (Groesse_seed+48) angehängt. Interessant dabei ist, dass das seed File nicht unbedingt mit einem vollständigen FLV frame endet. Spielt aber keine Rolle, da ja der Rest aus dem rienf File ergänzt wird.

 

Leider wird das resultierende File nur bis zum ersten korrupten Tag abgespielt. Eine Analyse mit dem flvcheck Programm von Adobe weist auf den ersten korrupten Tag hin.

 

Statt diesen zu überlesen sollte man vielleicht versuchen, ihn zu korrigieren. Möglicherweise ist lediglich das Feld mit der Länge des bodies falsch und muss korrigiert werden. Das werde ich mal probieren.

 

Grundsätzlich erscheint mir der Ansatz, das seed File als Basis zu nehmen, recht vielversprechend. Es hat den Vorteil, dass auch die Metadaten aus dem Seed File mit übernommen werden können.

[hackbart]

Guck dir mal die Timestamps an, da gibt es Überschneidungen. Ich hab's noch nicht getestet, aber die Länge bis zum ersten korrekten Paket in der rienf Datei entspricht fast der der FLV.

[dbraner]

Der Versuch, die Müllpakete in der rienf zu reparieren, indem man die Bodysize anpasst bis zum nächsten korrekte Paket bringt leider nichts. Die korrupten Abschnitte sind teilweise über 10 Kb groß während korrekte Pakete nur 500-600 Byte lang sind. Keine Ahnung, was die da machen. Wenn man die korrupten Teile weglässt, entstehen stumme Lücken im Audiofile von 1-2 Sekunden Länge. Das dürfte dann an den Lücken in den Timestamps liegen.

 

Dazu kommt, dass auch das letzte (anscheinend) korrekte Paket vor einem Garbage-Block nicht richtig ist. Am Ende eines jeden Pakets steht ja in einem DWORD die Gesamtgröße des Paketes. Das ist bei den Paketen vor einem Müllpaket auch falsch.

 

Hab jetzt eigentlich keine große Lust mehr, weiter daran zu arbeiten. Zumal die Napster Software gerade bockt und permanent irgendwelche Webzertifikate bestätigt haben möchte ohne jedoch eins anzuzeigen. Die Software ist wirklich die Seuche. Ich denke ich werde den Kram kündigen.

Edited April 1, 2012 by dbraner

[hackbart]

Ja schön ist wirklich anders - alleine schon das man die Fenstergröße nicht anpassen kann nervt. Ich hab schon einen konkreten Verdacht was genau falsch läuft mit den Blöcken - xor lässt Grüßen..

 

 

 

 

Christian

 

 

[Mr.Stag]

@Christian, dbraner,

 

mach Dir nicht viel Mühe mit XOR und so... Die (in jedem Titel an den selben Byteposition und mit identischer Größe eingestreuten) "Garbage"-Pakete werden von der Napster5-Software in Echtzeit beim abspeichern verschlüsselt und beinhalten u.a. ein TimeStamp-Flag, woran Napster 5 den Downlaod-Zeitpunkt festmacht und Dich z.B. auffordert, Dich wieder mit dem Internet zu verbinden, wenn Du zu lange offline warst und einen Titel offline abspielen willst.

 

Wenn Du die seed und rienf Datei wegspeicherst und den Titel erneut runterlädst, wirst Du sehen, dass genau die gleichen Blöcke wieder "Garbage" enthalten, diesmal aber völlig andere Daten. Die fehlenden Daten sind also nicht trivial wiederherstellbar.

 

Zwischen der (komplett unverschlüsselten) seed Datei und der rienf_Datei gibt es Überschneidungen in den Timestamps der FLV-Tags, dies ändert aber beim beliebigen Kombinieren leider nichts an den unspielbaren Blöcken in der rienf-Datei. :-/

 

Einfacher ist es hier, über ein Web-Debugging-Proxy den https-Traffic zwischen Napster5 und dem Rhapsody-Server mitzulesen, denn auf der Strecke ist die gesamte Datei beim Download unverschlüsselt (m4a-Datei) und man kann in weiteren Sessions auch JSON-formatierte Daten zu den Titeln finden, die ein späteres Taggen und Umbenennen einfach machen.

Edited April 1, 2012 by Mr.Stag

[dbraner]

mach Dir nicht viel Mühe mit XOR und so... Die (in jedem Titel an den selben Byteposition und mit identischer Größe eingestreuten) "Garbage"-Pakete werden von der Napster5-Software in Echtzeit beim abspeichern verschlüsselt und beinhalten u.a. ein TimeStamp-Flag, woran Napster 5 den Downlaod-Zeitpunkt festmacht und Dich z.B. auffordert, Dich wieder mit dem Internet zu verbinden, wenn Du zu lange offline warst und einen Titel offline abspielen willst.

 

Wenn Du die seed und rienf Datei wegspeicherst und den Titel erneut runterlädst, wirst Du sehen, dass genau die gleichen Blöcke wieder "Garbage" enthalten, diesmal aber völlig andere Daten. Die fehlenden Daten sind also nicht trivial wiederherstellbar.

 

Zwischen der (komplett unverschlüsselten) seed Datei und der rienf_Datei gibt es Überschneidungen in den Timestamps der FLV-Tags, dies ändert aber beim beliebigen Kombinieren leider nichts an den unspielbaren Blöcken in der rienf-Datei. :-/

 

Die Frage ist: reicht das Resultat aus dem Zusammenkopieren von seed und rienf File unter Weglassen der Garbage Infos für ein Matching mit iTunes Match. Muss ich mal testen. Andererseits kann ich mir auch die Arbeit und das Geld für Napster sparen und stattdessen gleich bei Amazon oder iTunes die Lieder kaufen. Dann habe ich auch keine 64 KBit Dateien.

[hackbart]

Nun ich denke mal ich werde erstmal die Finger von dem Projekt lassen. Man müsste den Code entschlüsseln und das ist dann wohl nicht wirklich legal. Die Alternative wäre, wenn man die im Cache liegenden unverschlüsselten Dateien identifiziert und tagged. Das geht u.U. dadurch das man in der FLV ein AAC Paket ausliest, im Speicher als Fragment hält und jede Mp4 Datei gegenprüft. Ein kleines Proof of Concept hatte ich anfangs diesbezüglich mal geschrieben, aber bei 3 Alben dauert das ne gefühlte Ewigkeit.

 

Christian

[LocalHolgi]

Das hört sich doch super an. Selbst wenn 10 Alben ne halbe Atunde bräuchten, wäre das bessere als alles manuell zu taggen. Planst du so ein Tool zu schreiben? Ich denke das würden sicher ne Menge Leute kaufen.

 

Holger

[hackbart]

Ich wünschte das wäre so einfach. Auf Rücksprache mit einem Anwalt bin ich mir aber sicher das selbst das Auslesen des Caches in Verbindung mit einem Taggen der unverschlüsselten Daten schon fraglich sein kann, denn der Begriff der "Umgehung“ die in § 95a bzw. 108b UrhG beschrieben wird, kann sehr großzügig ausgelegt werden.

 

Damit würde das Abgreifen der unverschlüsselten Daten vor der Konvertierung einen Eingriff in die „technische Maßnahme“ im Sinne des § 95a II UrhG darstellen. Verschlüsselung gilt als wirksame technische Maßnahme und deine Methode würde in diesen Prozess eingreifen. Man muss hier das Gesamtbild sehen und darf den Ablauf nicht in separate Schritte aufteilen.

 

Soll heißen solange nicht *hüstel* Napster/Rhapsody auf die Idee kommt und grünes Licht gibt, bleibt der Prototyp hier ein ebensolcher und dient einzig dazu meine Nächte weniger schlaflos zu lassen. Übrigens dauert das Erkennen von 10 Alben weniger als 20 Sekunden. Der Tagvorgang nebst kopieren ist ebenso schnell fertig.

 

Wie gesagt es handelt sich um ein Proof Of Concept der theoretisch funktioniert und gut ist. Ich lasse den Thread mal hier offen, aber von uns kommt wahrscheinlich nichts mehr aus dieser Richtung

 

Christian

 

 

[LocalHolgi]

Oh, kannst du eventuell einen Screenshot machen von deinem Programm? Ich weiß das klingt etwas doof, aber vielleicht spornt es ja andere an auch etwas in diese Richtung zu unternehmen.

 

Holger

PS: Ich bin halt verzweifelt, denn was nutzt mir mein Premiumpaket, wenn ich zwar laden kann aber im Offlinemodus die Daten rein gar nicht wiedergeben kann. Dauernd Online sein zu müssen und das auch für die Wiedergabe auf dem IPhone nervt.

[hackbart]

Naja, das ist ne komische Bitte, aber von mir aus. Ein Screenshot kann ja nichts schaden.

 

 

Wie gesagt das Tool wird sicher nicht weiter entwickelt und schon gar nicht verbreitet. Davon abgesehen bin ich mir eh nicht sicher ob nach einem Napsterupdate die MP4 Dateien weiterhin geladen werden.

 

Christian

 

 

[dbraner]

Oh, kannst du eventuell einen Screenshot machen von deinem Programm? Ich weiß das klingt etwas doof, aber vielleicht spornt es ja andere an auch etwas in diese Richtung zu unternehmen.

 

Holger

 

ich denke, das mit den Files im Browser-Cache ist auf die mit der heißen Nadel gestrickte Anwendung zurückzuführen. Das wird es nicht mehr lange geben. Und dann geht endgültig das Licht aus. Daher lohnt sich die Mühe für die Entwicklung einer Anwendung nicht wirklich.

 

[qupfer]

Für Otto-Normal-Nicht-Nerd-User ist es wohl am einfachsten das Album herunter zu laden, aus den Temp. Internet Files heraus zu kopieren und das ganze dann mittels Winamp AutoTag taggen zu lassen.

Problem ist halt nur, dass man auf die Gracenote DB angeweisen ist und gerade bei nicht Mainstream-Musik das nicht so zuverlässig läuft.

Anschließend stehts ein Qualitätsupdate via iTunes-Match auch nichts im wege^^ 64kbit/s Streams kann man noch auf 96+ "aufblähen" und dann Matchen lassen.

 

Natürlich nur im Moment, bis Napster das "fixt". Aber wenn die M4As dann immer noch unverschlüsselt zur Software gelangen, muss ja nur jemand einen entsprechenden "Proxy" basteln, der das dann mitschneidet.

Edited April 6, 2012 by qupfer

[hackbart]

Naja mit den Informationen die in der Datenbank stehen und den Zusatzdaten die man automatisch auslesen kann, geht ein taggen recht schnell von der Hand. Soll heißen 20 Alben kann man innerhalb von 1 Minute indizieren und das Konvertieren braucht weniger als 2 Sekunden. Zumindest eine schnelle Festplatte vorausgesetzt

 

Moderne Alben sind offensichtlich allesamt in AAC+ kodiert mit 64kbps. Was viele sicherlich ignorieren ist das AAC+ nicht mit Dinosauriern unter den Kompressionstechniken wie MP3 zu verwechseln sind. 64kbps ist vergleichbar mit 128kbps MP3's, das ist bei klassischen Stücken sicherlich nicht gerade viel, aber als wenig audiophil veranlagter Mensch höre ich bei einem 25mb großen Pop-Album keinen wirklichen Unterschied, zu dem Original auf CD. Ich glaube übrigens nicht das Napster die Kompressionsrate erhöht, da es keinen Sinn macht schon komprimierte Daten umzuwandeln. Da erhöht sich nur die Dateigröße und verlorengegangene Toninformationen sind da immmer noch verloren. Das ganze ist wie wenn man aus einem pixeligen JPEG-Bild ein PNG macht, in der Annahme das wäre besser.

 

Christian

 

 

 

 

 

[dbraner]

Moderne Alben sind offensichtlich allesamt in AAC+ kodiert mit 64kbps.

 

Kann ich so nicht bestätigen. 3 aktuelle Alben (wurden in den letzten 2 Wochen veröffentlicht) sind alle 192 KBit AAC.

 

Noch ein Tipp für ein Programm zum Taggen der m4a Dateien (sofern man die Tags kennt)

 

AtomicParsley: http://atomicparsley.sourceforge.net/

 

Ist ein Commandline Tool, das sich wunderbar aus einem selbst-gefrickelten Programm aufrufen läßt. Ich tagge damit m4a's, konvertiere sie aber nicht mehr, da sie direkt von iTunes gelesen werden können

Edited April 7, 2012 by dbraner

[edegl]

Zum Thema "rienf" Datei schaut bitte mal in diesen Post

 

http://www.spin-planet.de/2012/03/napster-5-0-und-tunebite/

vio sagte am 16. April 2012 um 18:46 : ...

 

Vielleicht ergibt sich daraus ein Ansatz...

[hackbart]

Interessieren würde mich die Information wie die Pakete in der rienf Datei verschlüsselt sind schon, aber wie gesagt ich hab das in den letzten Tagen nicht weiter verfolgt, da die rechtliche Situation derzeit wohl eher gegen so ein Tool spricht.

 

Christian

 

 

[vio]

Ja, in der Tat ist der rechtliche Aspekt hier das Problem.

Alternativ könnte man aber auch sagen, dass die Datei einfach nur kaputt ist und repariert wird

[LocalHolgi]

Ich wollte eigentlich nur Fragen ob es etwas neues gibt

 

Holger

[hackbart]

Naja Vio hat eine gute Anleitung geschrieben (zu finden via google) und damit kann man mit knapp 25 Zeilen Quellcode prima die Rienf "reparieren". Wie gesagt rechtlich eher fraglich.

 

Christian

[dbraner]

Naja Vio hat eine gute Anleitung geschrieben (zu finden via google) und damit kann man mit knapp 25 Zeilen Quellcode prima die Rienf "reparieren". Wie gesagt rechtlich eher fraglich.

 

Christian

 

Unterstützt das Microsoft CryptoAPI AES-CBC ?

[hackbart]

Das weiß ich nicht, ich habe die http://home.netsurf.de/wolfgang.ehrhardt/crypt_en.html Bibliothek zum Testen verwendet gehabt.

Christian

[LocalHolgi]

Ohweh nun isses wohl soweit, das neue Update von Napster speichert keine MP4's mehr temporär. Ich werde wohl meinen 3 Jahre alten Account wohl doch kündigen müssen - sauber das man das am Monatsanfang veröffentlicht und so noch mal nen Monat abfasst. Echt zum heulen, ich gehe wohl auch nicht davon aus das es Sinn macht einen offiziellen Rienf Converter zu veröffentlichen, da Napster dann wohl den Code wieder anpasst und weiter die Kunden gängelt. Blöder Mist mit dem Haufen.

 

Holger

[hackbart]

Lol, ja aber sind wir doch mal ehrlich das mit den MP4-Dateien im Cache war ja offensichtlich ein fetter Fehler von Napster. Wie du aber schon erkannt hast kann das Verschlüsselungsformat jederzeit nachträglich geändert werden. Da ich Napster nur als Hintergrundbeschallung nutze finde ich es primär aber nicht so schlimm.

 

Christian

 

 

[dbraner]

Ohweh nun isses wohl soweit, das neue Update von Napster speichert keine MP4's mehr temporär.

 

Jetzt gib mal die Hoffnung nicht so schnell auf und benutze Google. Das Hase - Igel - Spiel ist noch nicht zu Ende. Du muss die neue Version nicht installieren.