Musicload und die Wave-Dateien...


Status
Für weitere Antworten geschlossen.

Zwerg#8

Benutzer
Hallo Countie!

Die 42.622.976 Bytes (0x28A6000) stellen die Dateigröße "auf dem Datenträger" dar. Jede Datei belegt auf der Festplatte zumindest einen sog. "Cluster" - auch wenn sie nur 1 Byte groß ist. Unter Windows beträgt die Clustergröße üblicherweise 4096 Bytes (0x1000). Wird unsere Datei größer als 4096 Bytes, wird ein zweiter Cluster benötigt. Und so weiter.

Der Rest bis zum nächsten ganzzahligen Vielfachen der Clustergröße ist also "Verschnitt". Die wahre Dateigröße ist also maximal 4095 Bytes kleiner als diese Angabe.



Laut Header beträgt die Dateigröße

42.620.806 Bytes

In Hex haben wir also

0x28A5786

Runden wir auf die nächsten 0x1000 (Clustergröße) auf erhalten wir

0x28A6000

Und das sind 42.622.976 Bytes.




Aber das sollte doch eigentlich in diesem "Eigenschaften"-Fenster zu sehen sein. Du benutzt XP?
 

Nobier

Gesperrter Benutzer
Zwerg#8 du seniler Nerd ;) :thumbsup:

Ich denke das es unsauber/schnell gerippt wurde.
Wobei die clicks im ersten Song auch durch clipping enstehen können.
 

count down

Benutzer
Aber das sollte doch eigentlich in diesem "Eigenschaften"-Fenster zu sehen sein.

Tut es. Dort habe ich die Zahl abgelesen und gepostet. Ich dachte, sie würde zur Aufklärung zur Eingangsfrage von Boombastic beitragen. Aber trotzdem schönen Dank für das Referat über Clustergrößen und Hexen. Muss ich aber nicht verstehen, oder?
 

Nobier

Gesperrter Benutzer
Im ersten Song ganz am Ende, hört man dieses Blubbern auch.
Und zwar beim letzten Klavier Akkord. ;)
 

Zwerg#8

Benutzer
Moin!


Um sicher zu gehen:
Bei mir und einer Beispiel Wavedatei sehe ich üblicherweise zwei verschiedene Größenangaben. Die kleinere von beiden ist die richtige Dateigröße, die andere der belegte Speicherplatz.



Wenn bei dem File von BB beide Angaben gleich sind, dann ist zumindest der erste Header (nach "RIFF") falsch (zu klein).

BB müßte mal schauen, was nach dem Ende der Audiodaten im File noch kommt.


Grüßle
 

Anhänge

  • wavebeispiel.gif
    wavebeispiel.gif
    34,5 KB · Aufrufe: 23

Boombastic

Benutzer
Guten Tag, nach kurzem Urlaub bin ich jetzt auch mal wieder da...
Mein Eigenschaftenfenster verrät mir "40,6 MB (42.622.976 Bytes)" auf dem Datenträger.

In der Zwischenzeit hat mir auch der Support von Musicload geantwortet:

Der Verdacht, dass Ihre Dateien von einer geringeren Datei erstellt wurden, hat sich nicht bewahrheitet. Die WAVS/ Flacs sind ordnungsgemäß aus höheren AIFFS erstellt worden. Wir haben dies unabhängig prüfen lassen. Die Dateien wurden aus höherwertigen Material erstellt.

Ferner ist uns Ihr benanntes Problem mit den Header-Dateien bekannt und befindet sich ebenfalls in der Prüfung. Insbesondere prüfen wir den Sachverhalt im Hinblick auf einen Fehler bei der Erstellung des Headers. Sobald eine Rückmeldung eingetroffen ist, melden wir uns wieder bei Ihnen.

Dies deckt sich also mit Zwergs Aussagen, bzw. Kalkulationen.
Allerdings zweifel ich jetzt etwas an meinem eigenen Gehör, was die wahrgenommenen Fehler angeht - sind das wirklich (qualitative) Schnitzer bei der Produktion? Bin ich zu empfindlich? Gehört das so?
Muss jeder Poptitel heutzutage wie Fastfood gemastert werden?
Insbesondere fällt mir jetzt auch eine Beurteilung im Programm zunehmend schwieriger. A la haben die wieder Grütze ins MPN geladen/gibt es irgendwo in der Welt noch eine bessere Version?
Ich muss wohl einen Gang zurückschrauben und muss die Messlatte in Zukunft etwas tiefer hängen.

CU BB
 

count down

Benutzer
Bitte nicht vermischen: Für die Verkaufs-Downloadportale musicload, itunes, amazon etc. müssen Audio-Dateien im WAV-Format hochgeladen werden. Das MPN hingegen "frisst" nur flac-Dateien. Was da alles so von ahnungslosen Label-Mitarbeitern zur Bemusterung bereitgestellt wird, ist unvorstellbar. Wenn halt das finale Master noch nicht vorliegt, kann man ja auch locker mal eine 128er mp3 zur WAV und flac aufblasen. Ist ja nur fürs Radio. :(
 

dea

Benutzer
... Clustergrößen und Hexen. Muss ich aber nicht verstehen, oder?
Vielleicht doch. Zumindest schadet es nicht, eine ungefähre Vorstellung davon zu haben, wie Daten auf Datenträgern organisiert werden. Hier der Versuch einer kurzen, zusammenfassenden Erklärung, wobei sich das auch alles ausführlich woanders nachlesen lässt:

Damit ein Betriebssystem Dateien auf einen Datenträger schreiben bzw. von diesem lesen kann, braucht es eine Möglichkeit der Verwaltung, die üblicherweise "Dateisystem" genannt wird. Sicher sind dir Kürzel wie FAT12, FAT16, FAT32, NTFS (aus der DOS- Und Windowswelt) oder ext2/3/4 oder reiserFS aus der Linuxwelt schon mal irgendwo begegnet. All diese Systeme meinen Organisationsstrukturen und -methoden, wie Dateien (und Zugriffsrechte) auf Datenträgern verwaltet werden, die i.d.R. nur sog. Sektoren (512 Byte) anbieten. Im Wesentlichen besteht ein Dateisystem aus dem eigentlichen Speicherbereich für Daten, wo eine bestimmte Anzahl an (Hardware-)Sektoren zu einem Cluster zusammengefasst werden, und einer Zuordnungstabelle, die dann die Information aufnimmt, welche Datei welche Clusterbereiche auf der Festplatte tatsächlich einnimmt. Sehen wir mal von Spezialfällen ab und bleiben bei Windows, so kann man sagen, dass es wohl die meisten Benutzer heutzutage mit NTFS und seinen standardmäßigen 4 KB (4 * 1024 Byte -> 4096) Clustergröße zu tun haben. Auf USB-Sticks, SD-Karten u.ä. kommt sehr häufig FAT32 mit 8-KB-Clustern (suboptimal) zum Einsatz.
Je nach Art und Verwendungszweck des Datenträgers kann es hilfreich sein, andere Clustergrößen zu verwenden, wozu der entsprechende Datenträger mit den entsprechenden Parametern zu formatieren ist.

An der Stelle komme ich zu (seltenen) Kompatibilitätsproblemen bezüglich des Wave-Headers.
WaveLab-Benutzer sind möglicherweise schon mal über die angebotenen Optionen, sogenannte "Optimized Header" zu schreiben, sowie das Angebot, Marker ebenfalls in Headern zu speichern, gestolpert.
Beides sollte man besser nicht machen.

Ein "Optimized Header" wird auf die volle Größe eines Clusters auf dem Datenträger "aufgeblasen", sodass die eigentlichen Audiodaten erst exakt mit Beginn des nächsten Clusters geschrieben werden. Schon allein damit können die meisten Anwendungen nichts anfangen, denn wenn die Programmierer von einem Standard-Header ausgingen, dessen Größe ja fest definiert ist, werden sie alles, was nach dem angenommenen Header in der Datei steht, als Audio werten. Hier bestehen also sofort beste Chancen, Gaps, Clicks, Rauschen, vertauschte Kanäle oder ähnliches zu erhalten.
Noch schlimmer wird es, wenn man daran denkt, dass man ja in einem Rechner Datenträger haben kann, die verschiedene Dateisysteme mit verschiedenen Clustergrößen enthalten können. Das macht auch Sinn: Auf einem Laufwerk/einer Partition, die als reiner Audioserver dient, würde man normalerweise gar keine 4-KB-Cluster verwenden. Transportiert man Wavefiles auf SD-Karten oder von diesen herunter, hat man es oft mit 8 KB Clustergröße zu tun. Hält man sich an die Empfehlungen der SD Association und benutzt deren Formatting-Tool, hat man es automatisch mit 32-KB-Clustern zu tun. Das ergäbe dann schon ganz ein paar Sekundenbruchteile an Audioschrott; alles in allem genügend Raum, um aus einem (möglicherweise sogar aus Versehen) gesetzten Häkchen in einem Wave-Editor ein riesengroßes, folgenreiches Problem zu machen.

Was ich damit sagen möchte, ist vor allem: Nichts ist wichtiger, als die Optionen seiner Software und deren Wirkungsweise zu kennen. Wenn sie natürlich Fehler hat, die nicht offentlich sind, kann man schon froh sein, wenn man herausfindet, welches der Programme, mit denen man arbeitet, welchen Fehler macht und welches Programm in der Folge ausgerechnet damit nicht kommt.
__________

Zu dem im Eröffnungspost verlinkten Hörbeispiel:

Ich habe mir das gerade eben zum ersten mal angehört... grauenvoll.
Muss jeder Poptitel heutzutage wie Fastfood gemastert werden?
Ganz offensichtlich!

Das Dämliche an der Sache: Indem die Produzenten den Dreck derart brutal gegen die Wand fahren, wie in diesem Beispiel, machen sie ihre eigenen Fehler, die sonst kaum stören würden, auch noch deutlich hörbar.

Das Blubbern in Titel 1 könnte eigentlich gut auf Luftbewegung zurückzuführen sein. Zwischen Popscreen, Mikrofon und Interpret scheinen verdammt geringe Abstände geherrscht zu haben und da ja auch der leiseste Furz digital auf Anschlag gezogen werden muss, hört sich das an wie Rotz und Spucke.
Das Klavier leiert definitiv nicht. Ich kann mir auch nicht vorstellen, wie es das sollte, denn es wird weder von einem Turntable noch einem Senkel gekommen sein. Unharmonisch klingt es in den letzten Tönen aber tatsächlich. Ob das der Spielfehler eines Billig-Keyboarders ist, oder sogar Absicht war, ist nichts, was ich mit Sicherheit sagen könnte. Ich tendiere zu ersterem.
Für das kurze Störgeräusch im Ausklang habe ich keine handfeste Erklärung. Das klingt derartig diffus, dass es auf verschiedene Weise und in verschiedenen Stationen der Produktion entstanden sein kann, ist aber ein vergleichsweise geringes Übel.

Der zweite Track ist ganz klar keine 10 Cent wert und von dem für's Mastering Verantwortlichen bis hin zum Label verdient eine ganze Reihe Hirnies eine Woche Arrest mit 24-h-Beschallung dieses Titels. Wer solche Rechtecke veröffentlicht und dafür auch noch Geld nimmt, muss einfach hart bestraft werden. UNDISKUTABEL!

Seltsam hier allerdings: Auch in diesem Track blubbert es, ohne dass ich aber einen Zusammenhang zwischen dem Blubbern und dem Song ausmachen könnte. Läuft da also doch vormals fehlerhaft encodiertes Audio? Zumindest die FFT-Analyse sieht nicht auffällig nach Datenreduktion aus, was allerdings nicht heißt, dass die nie stattgefunden hat. Das kann man selbst dann nicht ausschließen, wenn Musicload beteuert, dass dem nicht so gewesen sei. Erstens müssen sie nicht die Wirklichkeit beschreiben, wenn das geschäftsschädigend wäre und sie genau wüssten, wie der Hase läuft. Zweitens glaube ich kaum, dass sie haarklein offengelegt bekommen, wie die Produktionen entstanden sind und welche Wege die Files wirklich genommen haben. Oder weiß jemand von einer QS nach ISO9001?
 

dea

Benutzer
Interessantes Tool. Danke für den Hinweis.

Und gleich mal getestet:

Im Anhang ein Stück für BB, da er offenbar so sensibel auf unharmonische Instrumentierung reagiert - viel Spaß!
(Shakatak - Dark Is The Night, 1983 Polydor Ltd., Comp. 1993 Karussell Ltd., 5500082).

Das Wave frisch von der CD gelesen und geschnitten, einmal mit normalem und einmal mit "optimiertem" Header (WaveLab 5) gespeichert... BWFEdit erkennt weder in dem einen noch dem anderen Wave einen Fehler. Ich halte das für eine großzügige Beurteilung angesichts der Tatsache, dass die optimierten Header tatsächlich problematisch sind.
 

Anhänge

  • Shakatak - Dark Is The Night (30 s sample).mp3
    1 MB · Aufrufe: 19
Und natürlich kann man auch nicht ausschließen, dass die "merkwürdigen" Sounds schon so in der Produktion verwendet wurden. Schließlich entstehen heutige Produktionen sehr oft über längere Zeiträume und die Audiotracks kommen aus den verschiedensten Quellen und Aufnahmesituationen. Dabei ist es ja dann fast schon zwangsläufig, das selten überall mit derselben Samplefrequenz, Bittiefe und Datenrate gearbeitet wird. Allerdings sollte man dies am Ende beim Mischen dann natürlich hören, sofern man diesbezüglich entsprechend geschult oder sensibilisiert ist und es einen überhaupt interessiert...:cry:
 
Im Anhang ein Stück für BB, da er offenbar so sensibel auf unharmonische Instrumentierung reagiert - viel Spaß!
(Shakatak - Dark Is The Night, 1983 Polydor Ltd., Comp. 1993 Karussell Ltd., 5500082).
.


...wie herrlich! Klingt aber eher nach Gleichlaufschwankungen bei für die Produktion verwendeten Bandmaschinen. Ja liebe MP3 Kinderlein, soetwas gab es mal, ist aber schon uuuhhnglaublich lange her und hat nicht unbedingt etwas mit den Plug In Emulationen zu tun, die Ihr vielleicht zu kennen glaubt...;) Zeigt aber ganz schön, dass man schon immer ggf. technisch Unperfektes produziert hat
 

Zwerg#8

Benutzer
Hallo dea!

Wenn die "optimierten Header" richtig sind, warum sollte BWFEdit dann meckern? Es ist ja nicht verboten, den "data"-Chunk an Offset 0xFF8 zu schieben (Die Audiodaten beginnen dann bei 0x1000.) In der Wavedatei muß sich davor halt nur ein Padding-Chunk ("PAD ") befinden, so wie das Wavelab ja auch macht. Diesen Chunk könnte ich sogar "dea " nennen, ohne daß ein Abspielprogramm daran scheitert, denn unbekannte Chunks müssen (sollten) stillschweigend überlesen werden.

Ich halte diese optimierten Header für gar nicht mal so schlecht, denn so ist gewährleistet, daß die Samples bei einem durch Vier teilbaren Offset beginnen. Im Ernstfall - versaute Header - kann man das File vollig problemlos als "RAW-PCM" importieren, ohne versehentlich "halbe Samples" zu schneiden. Du kennst ja sicher diesen alten Thread:

http://www.radioforen.de/index.php?...wird-nur-eine-viertelstunde-abgespielt.29644/
 

dea

Benutzer
Hallo dea! ... Du kennst ja sicher diesen alten Thread:

Jupp, kenne ich noch. Allerdings ist diese Angelegenheit echt ausschließlich etwas für Insider, die genau wissen, was sie da tun. Wissen sie das nicht, fallen sie erst recht auf die Nase, wenn sie im Fall "versauter Header" (Wave mit Überlänge) die RAW-Methode versuchen wollen. Den Start der Audiodaten finden sie dann niemals nach Anleitung im Netz, sondern nur mit Freak-Werkzeugen (Hex-Viewer/-editor).

Ich habe übrigens gerade mal auf die Schnelle probiert, ob von den Sachen auf dem Rechner hier die einfachsten mit dem Header klarkommen. Kommen sie, zumindest WMP (6.4 + 9), WinAmp, foobar, die LAME-Kommandozeile (3.99.5) und Audacity. Wer tatsächlich auf die Nase fällt, ist der MP3-Player (Cowon D2+). Dem hab ich das "optimized-Header"-Wave auf die SD-Karte gepackt. Er spielts vom Start an richtig, generiert aber am Ende der Datei einen Kracher, rasselt also offensichtlich in Bereiche auf der Karte, die nicht mehr Wave sind. Die Karte ist übrigens mit 32-KB-Clustern formatiert.
Jetzt müsste man noch einen Test machen, wie sich die Datei auf sämtlichen Dateisystemen mit verschiedenen Clustergrößen von all den Programmen verarbeiten lässt. Das ist mir aber just for fun ein bisschen zuviel Aufwand ohne erkennbaren Zweck.

Ja, nicht wahr? :) Hat man Spaß mit dem Song. Allerdings:
Klingt aber eher nach Gleichlaufschwankungen bei für die Produktion verwendeten Bandmaschinen.
Genau DAS sagte mir derjenige, der mich auf die Disharmonien aufmerksam gemacht hatte. Ich selbst bin eher mehr Rythmusmensch und habe mich über die ataktischen Schläge aufgeregt. Der Beat wirkt nämlich auch so gar nicht rund. Ich habe allerdings noch nie nachgemessen (man könnte ja mal Samples zählen), ob das auch eine akustische Täuschung ist. Das "Leiern" kann eigentlich unmöglich von einer Bandmaschine kommen, es sei denn, jemand hätte beim Überspielen händisch das Band gebremst oder einen Pitch-Regler betätigt. Wahrscheinlicher ist aber wohl ein zittrig betätigtes PitchBend-Rad eines Synthesizers. Krass sind aber die permanenten Obertöne, die irgendwie so gar nicht ins Spiel passen. Ich bin kein Musiker und habe von Harmonielehre eigentlich gar keine Ahnung, aber als Hörer fällt mir auf: Da stimmt was nicht. Ob das ernsthafte Absicht im Arrangement war oder Alkohol - wir wissen es nicht.

Ich sollte vielleicht noch anmerken, dass dieser Sound auch nur in diesem Instrumentalteil des Titels auftritt. Der Rest incl. Vocals klingen völlig OK, wobei der Titel insgesamt den Eindruck macht, halbherzig zusammen- bzw. auseinander geschnitten worden zu sein. Bei einem anderen Track fehlt auch unüberhörbar zeitweilig auf einem Kanal Pegel: Tonkopf zu. ;)
 

Boombastic

Benutzer
Der Musicload Support hat sich gemeldet:

Das Problem mit den defekten Headern wurde eingehend geprüft und die Ursache behoben. Sie können die erworbenen Titel sehr gerne erneut herunterladen, hierzu haben wir Ihre Lizenzen erhöht. (...)

Dann bekommt Musicload noch eine Chance von mir.
Danke für eure Mithilfe und die Bestätigungen - auch an Zwerg ;)
 

Zwerg#8

Benutzer
Moment Boombastic, wir sind noch nicht ganz fertig!

Hast du die neuen Dateien schon gesaugt?


1.) Meckert dein Datenbank-Progi immer noch beim Import der Dateien?
2.) Teste die alten und neuen Dateien doch bitte mal mit dem Programm aus #34 (Falls Fehler angezeigt werden, bitte posten.)
3.) Was sagt der Explorer zur _genauen_ Dateigröße? (Bitte nicht die "Größe auf dem Datenträger"! Ich will den kleineren Wert, falls es den gibt.)
4.) Ich hätte gern den neuen Header von "One Republic" im Hexviewer gesehen.

Soweit die Hausaufgaben. ;)

Grüßle
 

Boombastic

Benutzer
So, bevor ich zu den Punkten komme, habe ich nun die Daten neu heruntergeladen und mit der Kauf-CD verglichen, dh. auf zwei Spuren übereinandergelegt, an den Nulldurchgängen ausgerichtet, eine Spur invertiert, normalisiert.

Beobachtung:
- die Samples am Anfang und am Ende scheinen synchron - es fehlt nix, von vorne bis hinten synchron.
- eine der beiden Versionen unterscheiden sich durch eine sanfte Bearbeitung in der Dynamik bzw. durch ein schnelleres Fadeout - welches aber die Produktionsgüte nicht wesentlich beeinflusst.
- beobachtete Knackser, Störungen, Autotune-Zerrer sind in beiden Versionen identisch (!) bzw. heben sich nicht aus dem Differenzsignal heraus.

https://dl.dropboxusercontent.com/u/25307105/Forendateien/Differenzsignal.flac

Bei One Republic klingt es doch schon sehr merkwürdig:

https://dl.dropboxusercontent.com/u/25307105/Forendateien/Differenzsignal 2.flac

Diese Pulse kann ich mir nicht erklären. Fehler beim CD-grabben?

Nun zu Zwerg:

1.) werde ich wohl morgen wissen
2.) dito
3.) One Republic (alt): 42.620.762 Bytes / One Republic (neu): 42.620.806 Bytes
4.) kommt noch

CU BB
 

Zwerg#8

Benutzer
> 3.) One Republic (alt): 42.620.762 Bytes / One Republic (neu): 42.620.806 Bytes

Aha! Jetzt bekomme ich endlich díe wahre Dateigröße der "alten" Datei, nach der ich hier im Thread eigentlich schon immer explizit gefragt habe. Manno!


Die Dateigröße der "alten" Datei beträgt - wie wir jetzt endlich wissen - nur 42.620.762 Bytes. Damit ist die Größenangabe im Header der alten Date bei "RIFF" (42.620.806 Bytes) falsch - nicht zutreffend.

Und nun?

Die Datei ist damit genau 44 Bytes (!) kürzer, als die Angabe im Header vorgibt. Man muß sich also über die "Unexpected end of input data"- Fehlermeldung (von der du zu Beginn geschrieben hast) nicht weiter wundern.


Bei der Zahl "44" klingeln bei mir als "Wavedatei-(Aus)Kenner" natürlich sofort die Alarmglocken. Wer die hier verlinkten alten Threads wenigstens grob überflogen hat, dem ist diese Zahl sicherlich schon begegnet... These: Hat da jemand bei Musicload beim Proggen ein Offset vergessen? Kann durchaus passieren - Faselfehler.
 

Boombastic

Benutzer
Also, die neuen Audios scheinen problemlos zu funktionieren, jedenfalls klappte der Export/Konvertierung ins Sendeformat.
Auch das Programm BWF MetaEdit meldet keinen Fehler.
Hier zum Vergleich die Fehlermeldung bei der alten Datei: OneRepublic_If I Lose Myself_001_OneRepublic_If I Lose Myself.wav: invalid Wave: truncated




CU BB
 

Zwerg#8

Benutzer
Gut, dann hätten wir das auch geklärt. Da die Header in beiden Dateiversionen identisch sind, waren wohl die alten Dateien immer etwas zu kurz geraten. Und je nachdem, wie "gutmütig" eine Abspielsoftware ist, wird das so importiert/abgespielt, oder gemeckert. Kleiner Fehler, große Wirkung.
 

Zwerg#8

Benutzer
Hi!

Mal abgesehen von den falschen Headern, wisst ihr was wir bei der ganzen Aktion hier vergessen bzw. übersehen haben?

Schaut mal:
OneRepublic - If I Loose Myself (Universal)
Taylor Swift - I Knew You Were Trouble (Big Machine Records)

"Big Machine Records" gehört auch zu Universal...
http://en.wikipedia.org/wiki/List_of_Universal_Music_Group_labels

Und nun kommts: Hörbares "Watermarking", auch bei Wavedateien. Hier gehts los:

http://www.mattmontag.com/music/universals-audible-watermark



Grüßle
 

Nobier

Gesperrter Benutzer
Hi!

Mal abgesehen von den falschen Headern, wisst ihr was wir bei der ganzen Aktion hier vergessen bzw. übersehen haben?

Schaut mal:
OneRepublic - If I Loose Myself (Universal)
Taylor Swift - I Knew You Were Trouble (Big Machine Records)

"Big Machine Records" gehört auch zu Universal...
http://en.wikipedia.org/wiki/List_of_Universal_Music_Group_labels

Und nun kommts: Hörbares "Watermarking", auch bei Wavedateien. Hier gehts los:

http://www.mattmontag.com/music/universals-audible-watermark



Grüßle


haha. das ist doch nichts neues
 

Zwerg#8

Benutzer
Watermarking ist natürlich nicht neu. Es geht darum, daß eben auch die teuren Wavedateien gemarked sind, also nicht der von der CD gegrabbten Wavedatei entsprechen!



Boombastic schrieb oben:

> Bei One Republic klingt es doch schon sehr merkwürdig:
> Diese Pulse kann ich mir nicht erklären. Fehler beim CD-grabben?

Pulse?

Die "Pulse" klingen genau so wie das Differenzsignal unter "Audio Samples" im verlinkten Artikel.
 

Zwerg#8

Benutzer
Du bist auffallend schweigsam, Nobier. Ich frag nur sicherheitshalber nach. Fällt dir wenigstens ein cooler Spruch zum Thema ein. Du bist doch sonst immer vermeintlich "mächtig cool" drauf und müllst das Forum zu...

Hinweis: Wenn du das alles schon längst gewußt hast, warum schreibst du hier im Thread nichts davon?

*GRRRRRRRRRRRRR*
 

Boombastic

Benutzer
Ich habe wieder eine E-Mail an Musicload verfasst, denn es ergeben sich hieraus ja weitere Fragen:

1. welchen Inhalt hat das Wasserzeichen?
2. wird dieses benutzerbezogen generiert? -> Entscheidend für weiter Bearbeitung und Aussendung im Hörfunk.
Ich will nicht, dass bei einer Analyse meine ID auftaucht, weil ein Hörer einen Radiomitschnitt macht (legal) und verbreitet (illegal).
3. wie passt ein hörbares Wasserzeichen in das Konzept der höherpreisigen WAVE-Dateien, welche für "audiophile Musikgenießer" angeboten werden?

Die Logik sagt mir, dass dieses Wasserzeichen personalisiert ist, da die CD-Version als "Pressprodukt" dieses Wasserzeichen nicht trägt. Das wiederum würde bedeuten, dass das Wasserzeichen im Distributionssystem generiert wird und dem Titel aus der Datenbank hinzuaddiert (oder subtrahiert) wird. Folglich hätte Musicload Kenntnis von der ganzen Geschichte, hat Sie aber dem Verbraucher verschwiegen.

Ich bin auf die Antwort gespannt.

CU BB
 
Status
Für weitere Antworten geschlossen.
Oben