-
Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
Näheres könnt Ihr hier nachlesen: AGB-Änderung -
Viele hassen ihn, manche schwören auf ihn, wir aber möchten unbedingt sehen, welche Bilder Ihr vor Eurem geistigen Auge bzw. vor der Linse Eures iPhone oder iPad sehen könnt, wenn Ihr dieses Wort hört oder lest. Macht mit und beteiligt Euch an unserem Frühjahrsputz ---> Klick
iTunes und FLAC
- Ersteller Catholic
- Erstellt am
Bestechend sachliche Argumentation, einfach unwiderlegbar. Danke.
:-c
Aufgemerkt:
ALAC lässt sich auf jeder erdenklichen Softwareplattform abspielen, und wenn sich mal jemand bequemen würde selbst einen Encoder dafür zu erstellen, auch überall erstellen.
Der Softwaresupport für ALAC ist also schlecht.
FLAC dagegen lässt sich unter OS X nicht vernünftig benutzen, weil brauchbare Module nicht ums verrecken verfügbar sind. Und wenn doch, dann sind sie so instabil dass man heulen möchte. Unter Windows sieht es nicht viel besser aus. Der Softwaresupport für FLAC ist demzufolge sehr gut.
Ausserdem sind Unterschiede im Kompressionsgrad von etwa 1% ein absolut schlagkräftiges Argument, dem man sich einfach nicht zu entziehen vermag. In einer Zeit voller Flatrates, Terabyte-Platten und gigantischen optischen Medien, die problemlos tage- oder gar monatelange Aufzeichnungen speichern können, wird es von Tag zu Tag immer wichtiger, auch noch das allerletzte Bit aus seinen Soundfiles herausquetschen zu können.
Dazu sind weder Mühen noch Aufwand zu scheuen, wenn nur ja die sakrale Heiligkeit der binären Details eines mittlerweile 30 Jahre alten Datenformats "PCM" nicht angetastet wird. Denn das steinzeitliche Aufzeichnungsverfahren der Audio-CD ist der einzig wahre und wahrhaftige GOTT, dem man niemals abschwören darf.
Willkommen im geradezu Orwell'schen "Reality Distortion Field" der OSS-Sektenfuzzis.
Hier ist Schwarz das neue Weiss, und Weiss das bessere Himmelblau (falls man alle Abhängigkeiten zu Rosarot und Lila auflösen kann).
Muss man nicht verstehen, nur ganz ganz ganz fest dran glauben. Cheez!
MotMann
Kaiser Wilhelm
- Registriert
- 18.09.04
- Beiträge
- 174
Hmm... meinst Du das jetzt ernst? So wie ich es sehe, läuft ALAC NUR auf Apple Produkte. Weder mein Autoradio, noch andere MP3 Player, können damit etwas anfangen.
Wer hier ein 'Sektenfuzzi' ist solltest du doch noch einmal überdenken. Ich bin weder ein Fan von Apple selbst noch ein Linus Torvalds-Anhänger oder sonst etwas. Ich benutze einen Mac weil ich mit den meisten Dingen glücklich bin und es mir an vielen Stellen Arbeit erspart. Zum Thema zurück.
Also weder unter Windows XP, noch unter Ubuntu konnte ich irgendwelche Probleme finden Flac-Files abzuspielen und auf dem Mac funktioniert das mit dem VLC-Player ebenfalls völlig problemlos, andere Software habe ich unter OSX dafür noch gar nicht ausprobiert. Von daher behaupte ich mal, dass diese von dir genannte 'Instabilität' nicht existiert.
Was das Encoding angeht, nur zu dumm das ALAC closed-source ist und die lieben Menschen sich wieder einmal nur durch reverse engineering einigermaßen durchwurschteln konnten um einen frei verfügbaren Encoder zu kreieren.
So und wenn Apple sich zu fein ist 'brauchbare Module' für FLAC zu entwickeln, dann ist das jedenfalls nicht die Schuld von der Xiph.Org Foundation, sondern von Apple. Übrigens, auch wenn ich die Sinnhaftigkeit in Frage stelle, kann Flac auch auf verschiedenen mobilem Musikplayern abgespielt werden.
Was solls, du verstehst es ja sowieso nicht und würdest ALAC vermutlich über jedes andere Lossless-Format stellen.
VLC, mplayer - made by Apple.... Hmm.
Weder ein Autoradio noch ein MP3-Player sind eine Softwareplattform.
Auch auf der oben verlinkten Wiki-Seite wird Hardwaresupport extra behandelt.
(Und da siehts für FLAC keinen Strich besser aus, ganz nebenbei bemerkt.)
Zuletzt bearbeitet:
Überdacht. Resultat bestätigt.
...mit den gleichen Programmen, mit denen das auch unter OS X problemlos geht.
Diejenigen Progs, die das unter OS X nicht können, tun es auch unter Windows nicht.
Unter Ubuntu gibt es noch nicht mal eine auch nur ansatzweise vergleichbare Systemarchitektur für multimediale Inhalte, dort herrschen in dieser Hinsicht noch Zustände, die einen unwillkürlich an DOS erinnern. Das ist in dieser Hinsicht völlig aus der Wertung.
Schön, dass du dann wohl ein funktionsfähiges xiph Plugin für QuickTime besitzt, ich nicht. Bisher hat keine einzige Version davon ein System- oder QuickTime-Update überlebt. Frühere Versionen brachten regelmässig Programmabstürze mit sich. "Instabil" ist noch sehr milde formuliert für diesen jämmerlichen Murks. (Andere Anbieter hatten da seltsamerweise keine Probleme damit.)
Man weiss also, wie es zu decodieren ist, aber das encodieren ist dennoch ein unergründliches Mirakel?
Sieh mal an, kommt man in der OSS Szene dann doch nicht ohne Quellcodes zum davon abschreiben aus? Dann hat also SCO möglicherweise gar nicht so unrecht, hm?
Aber Hoppla. Den gibt es doch angeblich gar nicht? Also was denn nun?
Aha. Das Format ist also von so fähigen Entwicklern gemacht, dass Apple das doch gefälligst selber zu tun hat. Verstehe. Eine voll Plugin-fähige Architektur auf die Beine zu stellen genügt noch nicht, man soll den konsequent unkooperativen Klienten gefälligst auch noch gebratene Tauben in den offenen Mund flattern lassen wie im Schlaraffenland...
Wie sieht das eigentlich bei der absolut grottenschlechten Unterstützung für QuickTime Videos unter Linux aus, hat da gefälligst auch Apple alles notwendige zu liefern? Weil die sich doch gefälligst um alles kümmern sollen, was die OSS Leute selbst nach über einem Jahrzehnt dauerhaften Aussitzens noch nicht auf die Rolle bekommen, ja?
ALAC ebenfalls. Und weiter?
Irrtum. Ich verstehe nur nicht so ganz, warum es unter den diversen anderen Formaten zu stehen hätte. Nur weil es für den Hinz&Kunz-Player oder MurksOS nicht auch noch kostenlos verfügbar gemacht wird.
MotMann
Kaiser Wilhelm
- Registriert
- 18.09.04
- Beiträge
- 174
Was ist denn das für eine dümmliche Antwort ...
Noch so was ... weia ..
Sag mal, kann es sein, dass du meine Frage nicht verstanden hast? VLC ist Software und keine Hardware. Und mein Autoradio kann CDs lesen. Dummerweise nur kein Apple Lossless, aber sehr wohl Flac usw... und natürlich liegt es an der Software in der Hardware.
Du scheinst dieses aber durcheinander zu schmeißen. Flac läuft fast überall problemlos. Probiere das mal mit ALAC, da wirst Du Trauer haben. Aber das scheint dir entgangen zu sein, dass ALAC nirgends unterstützt wird.
Schade um die Zeit.
@ navi: Lass es sein. Es macht keinen Sinn
Pure Logik. Da ALAC ja angeblich nur auf Apple Produkten läuft, müssen VLC und mplayer ja wohl von Apple sein, oder etwa nicht? Einwände?
Deine Frage war, ob ich das ernst meine.
Ja, ich meine es ernst, dass Autoradios oder MP3-Player keine Softwareplattform sind.
Und ja, ich meine doch die Frage verstanden zu haben. Hast du auch die Antwort verarbeitet?
Ach nee. Und es war auch gar nicht von Softwareplattform die Rede, nein?
Schön für dich, wenn FLAC bei dir läuft. Hier bei mir im Wohnzimmer steht dafür ein DVD-Player, der zwar AAC und ALAC spielt, aber weder Ogg noch FLAC. Und der ist nicht von Apple, sondern von Phillips. So what?
Mit dieser Einstellung solltest du vielleicht besser zu Windows und WMA-Lossless switchen. Dort sitzen mit Abstand die meisten der sprichwörtlichen Fliegen herum.
Einfach mal die *.m4a Dateien in *.mp4 umbenennen. Hopperla! Zauberei!
Ja das meine ich und sehe mich erneut betätigt.
Oh man...Rastafari schrieb:
Flac und OSX bzw. iTunes (denn mit alternativen Playern wie Play läuft Flac problemlos unter OSX). Das Problem liegt bei Apple.
"However, iTunes is a proprietary software which does not provide a way to expand directly it's audio formats handling functionality by third-party developers. Given the iTunes support for QuickTime formats and architecture, writing a QuickTime extension (a component) has an effect of indirectly extending iTunes functionality. Unfortunately, iTunes support for QuickTime formats and extension mechanisms seems to be very selective - it is not even clear what exactly is supported as there is no single page of documentation about it."
http://xiph.org/quicktime/faq.html
Nachmal zu ALAC:
David Hammerton and Cody Brocious have analyzed and reverse-engineered this codec without any documents on the format. On March 5 2005 Hammerton published a simple open source decoder in the C programming language on the basis of their work.
http://wiki.hydrogenaudio.org/index.php?title=ALAC
Lossless comparison: http://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison
Zuletzt bearbeitet:
Ich hol' den Thread nochmal raus, es gibt Neuigkeiten. Bei arstechnica wird heute über ein (Apple)Script berichtet, mit dem man FLAC-Dateien in die iTunes Library importieren kann. Nachteil: Es kann immer nur eine Datei importiert werden. Download
Wurde von mir auf 10.5.4 und iTuses 7.7 getestet, und für gut befunden.
Wurde von mir auf 10.5.4 und iTuses 7.7 getestet, und für gut befunden.
Blödfug. Die xiph-Plugins funktionieren nicht. Wer hat den Mist kodiert? Apple etwa?
Eine glatte Falschbehauptung, denn das Zitat bezieht sich rein auf die integrierten Encoder.
iTunes unterstützt zur Wiedergabe ***JEDES*** geeignete QT-Plugin.
Sofern es überhaupt **funktioniert**. Was bei xiph einfach nicht der Fall ist.
Das müssen sie auch behaupten, sonst erklären sie sich einer Lizenzverletzung schuldig.
Glaubwürdigkeit: massenvernichtungswaffenverdächtig hoch.
Würdest du diese Quellcodes lesen, fändest du einen simplifizierten und ein wenig umständlich realisierten Paketparser für MP4-verpackte AAC-Streams vor, nur ohne den danach angeflanschten Decoder - weils den nicht braucht.
Ist natüüüürlich ein reiner Zufall, dass eine lizenzpflichtige Teilkomponente für das Abspielen von MPEG-4 Audio und eine freie Soft für einen gaaaaaaaanz anderen Zweck im Endeffekt genau das gleiche mit zwei nur geringfügig unterschiedlichen Algorithmen tun. Nicht wahr?
Die Behauptung, man hätte diese Soft selbst entwickeln "müssen", ist eine blanke Lüge.
Man hat es nur deshalb "getan", um sich nicht dem Vorwurf eines Plagiats auszusetzen. Manche Leute aus der OSS-Szene haben diese Worthülsen schon ziemlich aalglatt drauf.
Und ein Haufen Sektierer glaubt ihnen unbesehen einfach alles.
hallo liebe apfelhasser....
man man man, was ist denn hier los ? was machen apfelhasser in diesem forum ?
natürlich gibt es eine ( sehr einfache ) möglichkeit flac dateien in itunes zu importieren.
http://cubicfruit.com/fluke/
diese programm herrunterladen. installieren.
wichtig, danach itunes neu starten.
die zu importierende datei rechtsklicken, öffnen mit .... ( hier FLUG auswählen, am besten "immer öffnen mit" anklicken )
die datei wird umgewandelt und automatisch in itunes importiert.
dort liegt sie als quicktime film vor und kann ohne probleme in apple loseless umgewandelt werden.
funktioniert auch mit der aktuellen itunes version.
viel spaß beim encoden ......
man man man, was ist denn hier los ? was machen apfelhasser in diesem forum ?
natürlich gibt es eine ( sehr einfache ) möglichkeit flac dateien in itunes zu importieren.
http://cubicfruit.com/fluke/
diese programm herrunterladen. installieren.
wichtig, danach itunes neu starten.
die zu importierende datei rechtsklicken, öffnen mit .... ( hier FLUG auswählen, am besten "immer öffnen mit" anklicken )
die datei wird umgewandelt und automatisch in itunes importiert.
dort liegt sie als quicktime film vor und kann ohne probleme in apple loseless umgewandelt werden.
funktioniert auch mit der aktuellen itunes version.
viel spaß beim encoden ......
Wo sind hier Applehasser? Ist Kritik nicht erlaubt?
Das geht zwar und ist ein Fortschritt.
Das Skript kannte ich vor einigen Monaten noch nicht. Aber optimal ist etwas anderes, denn es wird getrickst, da der FSType geändert wird. Was Rastafari sich zusammenschreibt ist nicht zum aushalten. Am besten ignorieren...
Der weiss offenbar überhaupt nicht wovon er postet und wirft so einiges wild durcheinander... ganz von ab, dass ich von iTunes in erster Linie gesprochen habe. An Fluke sieht man es ja auch. zum Beispiel:
http://article.gmane.org/gmane.comp.video.ffmpeg.devel/19686
Das steckt heute in libavcodec drin. Den nutzt z.B. VLC.
Ganz einfache Frage:
Wo kann man denn ALAC lizensieren? Wo gibt es denn die Specs von ALAC offiziell zum nachlesen bei Apple, um z.B. dafür "selbst einen Encoder [..] zu erstellen"? Also so, dass man nicht auf die Ergebnisse des Reverse-Engineering zurückgreifen muss, was letztlich auch nicht optimal ist. Denn was ist, wenn Apple die Specs ändert? Berücksichtigt der reverse-engineered Decoder tatsächlich jeden möglichen Fall, oder kommen die nur mit den Erzeugnissen von Apples derzeitigem Encoder klar?
In dBpoweramp kann man ebenfalls nach ALAC encodieren. Habe ich schon gemacht und es läuft bisher ohne Probleme. Das hat aber auch schonmal zu Problemen geführt: http://forums.sonos.com/showpost.php?p=27176&postcount=5
Keine Ahnung wie Spoon den Encoder implementiert hat: http://forum.dbpoweramp.com/showthread.php?t=10154
Ich nehme mal an, dass er ebenfalls auf die Ergebnisse von dem Reverse Engineering zurückgreift.
PS:
Und der kann ALAC - mit dem Segen von Apple? Das bezweifel ich, bis ich es nachlesen kann. Wie nennt sich das Modell denn? Der kann bestimmt nur AAC (was du scheinbar teilweise mit ALAC verwechselst).
Zuletzt bearbeitet:
Och... überhaupt gar nichts.
Code:
[SIZE="2"]dude@Minimax[~]$ AtomicParsley /Users/dude/Desktop/audioloop.m4a -T0
Atom ftyp @ 0 of size: 32, ends @ 32
Atom moov @ 32 of size: 16426, ends @ 16458
Atom mvhd @ 40 of size: 108, ends @ 148
Atom trak @ 148 of size: 13942, ends @ 14090
Atom tkhd @ 156 of size: 92, ends @ 248
Atom mdia @ 248 of size: 13842, ends @ 14090
Atom mdhd @ 256 of size: 32, ends @ 288
Atom hdlr @ 288 of size: 34, ends @ 322
Atom minf @ 322 of size: 13768, ends @ 14090
Atom smhd @ 330 of size: 16, ends @ 346
Atom dinf @ 346 of size: 36, ends @ 382
Atom dref @ 354 of size: 28, ends @ 382
Atom url @ 370 of size: 12, ends @ 382
Atom stbl @ 382 of size: 13708, ends @ 14090
Atom stsd @ 390 of size: 88, ends @ 478
Atom alac @ 406 of size: 72, ends @ 478
Atom alac @ 442 of size: 36, ends @ 478
Atom stts @ 478 of size: 32, ends @ 510
Atom stsc @ 510 of size: 40, ends @ 550
Atom stsz @ 550 of size: 11272, ends @ 11822
Atom stco @ 11822 of size: 2268, ends @ 14090
Atom udta @ 14090 of size: 2368, ends @ 16458
Atom meta @ 14098 of size: 2360, ends @ 16458
Atom hdlr @ 14110 of size: 34, ends @ 14144
Atom ilst @ 14144 of size: 428, ends @ 14572
Atom ©nam @ 14152 of size: 43, ends @ 14195
Atom data @ 14160 of size: 35, ends @ 14195
Atom cpil @ 14195 of size: 25, ends @ 14220
Atom data @ 14203 of size: 17, ends @ 14220
Atom pgap @ 14220 of size: 25, ends @ 14245
Atom data @ 14228 of size: 17, ends @ 14245
Atom tmpo @ 14245 of size: 26, ends @ 14271
Atom data @ 14253 of size: 18, ends @ 14271
Atom ©too @ 14271 of size: 36, ends @ 14307
Atom data @ 14279 of size: 28, ends @ 14307
Atom ---- @ 14307 of size: 103, ends @ 14410
Atom mean @ 14315 of size: 28, ends @ 14343
Atom name @ 14343 of size: 27, ends @ 14370
Atom data @ 14370 of size: 40, ends @ 14410
Atom ---- @ 14410 of size: 162, ends @ 14572
Atom mean @ 14418 of size: 28, ends @ 14446
Atom name @ 14446 of size: 20, ends @ 14466
Atom data @ 14466 of size: 106, ends @ 14572
Atom free @ 14572 of size: 1886, ends @ 16458
Atom free @ 16458 of size: 888, ends @ 17346
Atom mdat @ 17346 of size: 18143937, ends @ 18161283
------------------------------------------------------
Total size: 18161283 bytes; 45 atoms total. AtomicParsley from svn built on Aug 5 2007 (utf8)
Media data: 18143937 bytes; 17346 bytes all other atoms (0.096% atom overhead).
Total free atom space: 2774 bytes; 0.015% waste. Padding available: 2774 bytes.
------------------------------------------------------
Movie duration: 240.000 seconds (04:0.00) - 604.80* kbp/sec bitrate (*=approximate)
Low-level details. Total tracks: 1
[COLOR="Blue"]Trk Type Handler Kind Lang Bytes
1 soun [none listed] alac und 18143929
604.80* kbp/s 240.000 sec Apple Lossless channels: [2][/COLOR]
dude@Minimax[~]$
[/SIZE]Nicht das gleiche Wintermärchen, das sich ein paar Code-Abkupferer (vulgo: "Plagiatoren") zurechtgelegt haben, um die "Ähnlichkeit" ihres Binärcodes mit dem von Apple schönzureden. Also wenn ich mir deren Behauptungen so zu Gemüte führe, von wegen "... Of course I've never seen their source code, but it's similar to their binary code. My implementation is written in medium-level C. ..."
...dann könnte ich kotzen. Das sind ein paar per Cut&Paste entnommene und geringfügig modifizierte Codefragmente, nichts anderes.
Die mathematische Wahrscheinlichkeit, dass zwei sich deutlich unterscheidende Compiler aus zwei unabhängig voneinander geschriebenen Quellcodes von diesem nicht trivialen Umfang auch nur einen aufs geringfügigste "ähnlichen" Binärcode erzeugen, die ist so gering wie die Chance, dass sich morgen früh um Punkt 9:27h sämtliche Sauerstoffmoleküle des Universums verabreden, simultan einen halben Meter nach Rechts zu hüpfen.
Das sind hohle Lügen, die sogar einen Münchhausen noch ehrlich aussehen lassen. Noch dreisteren Codeklau findet man selten, höchstens bei der Gang aus Seattle.
Ganz brilliant gestochen, Mr. Mücke.
Nur leider in die eigene Backe.
Bilder sagen mehr als tausend Worte: Rechts im Bild läuft eine alte PPC-Version von VLC in Rosetta. Die beinhaltet unangenehmerweise noch gar kein "libavcodec" (das gabs nämlich noch gar nicht zu der Zeit).
ALAC abspielen geht damit dennoch. Very, very strange... hm? Womit macht er das denn?
Leiht der PPC-Player sich etwa auf ganz magische Weise eine x86-Lib aus dem anderen Programmpaket und kann sogar was damit anfangen? Oder wie?
Dein "selbstgestrickter" Code hat also schon astrein funktioniert, noch bevor er überhaupt verwendet wurde?
Besser sogar: Sogar noch bevor er "programmiert" wurde, denn ich hatte mal eine 0.5x (oder 0.6x ?) Version von VLC, die das damals auch schon beherrschte mit der ALAC-Wiedergabe. Der Ton hatte zwar erhebliche Aussetzer und der Player schmierte auch schon mal nach 2-5 Sekunden ab, aber der Inhalt war eindeutig schon hörbar. Und das funktionierte schon etwa ein halbes Jahr lang, bevor Apple den ach so mirakulösen ALAC erstmals der Öffentlichkeit vorgestellt hat!!!
(Das einzige was sich aus Benutzersicht verändert hat: Aus dem damals noch im Infofenster angezeigten 4cc "mp4a" wurde ein "alac".)
Vornehm britisch formuliert: "Hochinteressant es ist, ist es nicht?"
Muss man das? Muss man das können?
Musst du das dürfen? Muss man dir das erlauben?
Sind QuickTime, MP4 und ALAC etwa Teil von Darwin, hat das irgendwelchen Bezug zur BSD-Herkunft?
In Anbetracht der Tatsache, dass es mindestens 1000 ausführliche und bemerkenswert präzise verfasste TechNotes zu allen möglichen Aspekten des Mac und seinem OS gibt, die von der bocksturen OSS-Gemeinde sträflich ignoriert werden; obwohl sie eine (erlaubte) Adaption davon technisch gut und gerne 10 Jahre in die Zukunft katapultieren könnte, ist das Argument der blanke Hohn. Was Apple nämlich alles veröffentlicht - das will komischerweise niemand mehr haben. Sei es auch noch so gut gemacht.
"Reverse"???
"Zurück in die Zukunft" meinst du?
Auf so eine Idee kann nur kommen, wer genau das woanders permanent erlebt.
Wer Apple kennt, der weiss genau: Die halten Abwärtskompatibilität grundsätzlich bis zur absoluten Schmerzgrenze aufrecht.
Kommt dein CD-Player mit Schallplatten klar?
Und, hat dich das auch nur im geringsten abgehalten einen zu benutzen?
Phillips DVP-520
Dafür spielt er aber die Lossless-Files von iTunes verdächtig gut ab.
Verwechseln? Naja, vielleicht sind ja alle bläde ausser dich. Kann ja sein. Gell?
http://en.wikipedia.org/wiki/Apple_Lossless
"Apple have not released any technical documents on Apple lossless, 3rd-party manipulation of Apple Lossless files are solely to the reverse engineering work of David Hammerton [craz.net]."
http://www.applelossless.com/
http://craz.net/programs/itunes/alac.html
http://www.m4if.org/mpeg4/
Wo ist denn ALAC Teil des Standards?
Apple Lossless ist in 0.8.2 hinzugekommen: Support for Apple Lossless Audio Codec
Weisst du wann 0.8.2 des VLC erschienen ist? Am 2005-07-05. Das ReverseReengineering hat bereits vorher stattgefunden.
Aber darum geht es garnicht.
Was hindert Apple denn daran, z.B. den ALAC-Bitstream in Zukunft noch etwas aufzubohren, wenn denen auffällt, dass man vom Kompressionsgrad tendenziell eher hinten liegt? Berücksichtigt der reverse-engineered Decoder tatsächlich jeden möglichen Fall? Da ist eben nichts wirklich abgesegnet. Oder wo ist der OpenSource-Code oder Specs bzgl. ALAC von Apple?
Da steht nichts von ALAC.
Also zusammengefasst:
- Wo ist ALAC standardisiert?
- Wo gibt es denn den offizielle Source-Code zu ALAC?
- Wo gibt es denn die Specs zu ALAC?
Butter bei die Fische!
"Apple have not released any technical documents on Apple lossless, 3rd-party manipulation of Apple Lossless files are solely to the reverse engineering work of David Hammerton [craz.net]."
http://www.applelossless.com/
http://craz.net/programs/itunes/alac.html
Und? Was willst du jetzt zeigen? Dass du mal wieder etwas durcheinander wirfst und du nicht den Unterschied zwischen einem Container und einem Standard kennst?
http://www.m4if.org/mpeg4/
Wo ist denn ALAC Teil des Standards?
Was hat das mit dem Thema zu tun - ausser dass es die Problematik von ALAC unterstreicht?
Ja und? VLC hat davor dann halt auf etwas anderes oder eigenes gesetzt, als libavodec. Das spielt doch keine Rolle. Rechts in deinem Bild ist VLC 0.8.6.
Apple Lossless ist in 0.8.2 hinzugekommen: Support for Apple Lossless Audio Codec
Weisst du wann 0.8.2 des VLC erschienen ist?
Am 2005-07-05. Das ReverseReengineering hat bereits vorher stattgefunden. Wie will es sonst ein Hersteller legal ohne mögliche Probleme implementieren? Ist ja nicht OpenSource. Ein proprietärer Codec, der nicht standardisiert ist und zu dem es keine Specs gibt (bzgl. Implementierung), ist keine gute Ausgangslage. Und ein reverse-engineered Decoder auch nicht.
So, wo sind denn die Dokumentationen von Apple bzgl. ALAC? Oder wo ist der SourceCode? Na?
Ein Format, das nicht standardisiert ist oder als OpenSource vorliegt, taugt nur beschränkt zur Langzeitarchivierung. Apple und die Abwärtskompatibilität. Alles klar
Aber darum geht es garnicht. Was hindert Apple denn daran, z.B. den ALAC-Bitstream in Zukunft noch etwas aufzubohren, wenn denen auffällt, dass man vom Kompressionsgrad tendenziell eher hinten liegt? Berücksichtigt der reverse-engineered Decoder tatsächlich jeden möglichen Fall? Da ist eben nichts wirklich abgesegnet. Oder wo ist der OpenSource-Code oder Specs bzgl. ALAC von Apple?
http://www.p4c.philips.com/files/d/dvp520_00/dvp520_00_pss_aen.pdf
Da steht nichts von ALAC.
Also zusammengefasst:
- Wo ist ALAC standardisiert?
- Wo gibt es denn den offizielle Source-Code zu ALAC?
- Wo gibt es denn die Specs zu ALAC?
Butter bei die Fische!
Zuletzt bearbeitet:
Sorry, aber ein "MPEG-4 Audio" ist kein Standard. Aber "AAC" ist sehr wohl einer, und darauf bezog sich ganz konkret der zweite Satz der Frage. Also kann im ersten Satz doch wohl nur der Container gemeint gewesen sein. Oder nicht?
Nun, falls nicht, dann sprechen wir beide wohl nicht ganz die gleiche Sprache.
Nirgends. Das hätte wer behauptet?
Ach so. Nicht der Dieb selbst, sondern das Diebesgut oder gar der Bestohlene sind also ein Problem. Interessantes Weltbild, irgendwie.Was hat das mit dem Thema zu tun - ausser dass es die Problematik von ALAC unterstreicht?
Könnte es zufällig "libmp4_plugin.dylib" gewesen sein?
Hmm, das hat bestimmt rein gar nichts mit MPEG-4 zu tun. Ganz sicher nicht.
Ab dieser Version wurde es offiziell unterstützt und lief auch einigermassen stabil.
Wie eine viel früher erschienene Version, die einen angeblich absulut fremdartigen Codec doch gar nicht kennen kann, diesen doch zumindest bruchstückhaft entschlüsseln kann, brauchst du dich nicht weiter zu fragen.
Das ist nämlich sicher nur einer dieser Zufälle...
Der grösste Teil war bereits implementiert. Weil eben ALAC nie so etwas wahnsinnig neues war.
Bist du schwer von Begriff? (Ist die Schreibweise so eine Art literarisches Tourette-Syndrom?)
Im Besitz von Apple natürlich. Und, weiter?
Wozu bitte sollte man denn Audiodaten einer Langzeitarchivierung ausgerechnet in einem Format zuführen wollen, das auf die Rekonstruktion des Signals anhand einer bis dahin längst vergessenen Speichertechnik namens "CD" limitiert ist?? Mit nur zwei Tonkanälen? Was'n das?
Glaubst du allen ernstes, im Jahr 2038 werden deine Enkelkinder sich am majestätisch anmutenden Klangspektakel heutiger Musik erfreuen wollen? Dagegen wirkt ja sogar das Sammeln abgestempelter Briefmarken in einer klimatisierten Vakuumkammer noch recht wohldurchdacht und realitätsverbunden.
Das Grinsen an dieser Stelle wirkt peinlich, fast schon infantil.Apple und die Abwärtskompatibilität. Alles klar
Welcher andere Anbieter könnte eine ähnliche Kontinuität seiner selbst entwickelten Formate vorweisen? Vorschläge?
Ich rechne eher mit einem Übertritt des Papstes zum Islam.
Furchtbar frappierende Unterschiede in der Grössenordnung von 62 zu 61,4% dürften bei einem ohnehin mausetoten Thema unter den Entwicklern ungeahnte, nie dagewesene Personal- und Geldresourcen dafür mobilisieren. Schon klar.
Ich weiss. Geht aber trotzdem.
Von DivX Support steht da auch nichts, geht ebenfalls.
Wunder, oh Wunder.
ISO/IEC 14496-3:2005 (MPEG-4 Audio): http://www.iso.org/iso/catalogue_detail.htm?csnumber=42739
ISO/IEC 14496-3:2005/Amd 2:2006: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43026
Es ging hier nie um AAC, sondern immer nur um ALAC. Und ALAC ist kein Standard. Du scheinst AAC nicht von ALAC unterscheiden zu können.
Natürlich geht es um den Standard - denn es geht hier um die Problematik bzgl. ALAC und warum Flac besser ist. Flac ist nämlich "wenigstens" OpenSource. ALAC ist weder OpenSource noch standardisiert.
Eben.
Er hat das über ReverseReengineering erreicht, denn es gibt keinen öffentlichen SourceCode von ALAC. Das ist ja die Problematik und damit bestärkst du meine Argumentation.
Wenn es nicht libavcodec gewesen sein sollte, dann ist im VLC etwas anderes oder eigenes benutzt worden, das auf den Ergebnissen des ReverseEngineering beruht. Als dann libavcodec soweit war, hat man es genutzt.
ALAC hat auch nichts mit MPEG-4 Audio zu tun!
Lügner? Im Log steht davon nichts.
Das spielt aber auch keine Rolle, denn selbst wenn das was du schreibst stimmen sollte (was ich bezweifel), stärkst du mal wieder meine Position, denn man sieht daran, wie kompliziert und allein man ist, da es keine Specs gibt.
Hättest du meine Links gelesen, dann hättest du bei audiohq folgendes gelesen:
"Nach einigen Recherchen habe ich herausgefunden, dass weder Apple Lossless noch RealAudio Lossless etwas mit AAC zu tun hat! Wäre ALAC nämlich AAC-Lossless, würde jeder m4a/AAC-Player ALAC wenigstens lossy wiedergeben können. Dies ist jedoch nicht möglich, da ALAC ein lossless-only Codec ist. Mehr dazu später.
Die Herkunft von ALAC ist ungeklärt. Es ist jedoch auffällig, dass Apple im Jahre 2002 Emagic übernommen hat. Mit Emagic ging auch ZAP ( ein von Markus Fritze in den 90ern entwickelter Lossless-Codec) in den Besitz von Apple über. Es ist daher nicht unwahrscheinlich, dass ALAC eine weiterentwickeltes ZAP ist. Apple hätte sich dadurch die Neuentwicklung eines Codecs bzw. die Lizenzkosten für einen Codec einer anderen Firma gespart."
http://www.audiohq.de/index.php?showtopic=1407
Wenn an deiner Behauptung etwas dran ist, dann wird das vielleicht der Grund sein. Aber das spielt gar keine Rolle. Und die lossless-Codecs sind sich häufig recht ähnlich. Trotzdem sind es unterschiedliche Codecs. Der User "pest" bei 3dcenter hat z.B. seinen eigenen Lossless Codec geschrieben (Sac).
Edit: Alte VLC-Versionen gibt es z.B. hier: http://www.oldapps.com/VLC_Player.php?old_vlc=17#Download
Der VLC 0.6.0 bleibt bei mir bei ALAC still.
Siehe audiohq-Link.
So, wo gibt es denn den SourceCode zu ALAC, den man für eigenen Encoder und Decoder nutzen kann?
Du bist eher schwer vom Begriff. Eben, die Specs und der Code sind im Besitz von Apple und die geben AFAIK nichts raus. Wie soll dann jemand ohne Reverse-Engineering einen Encoder selber entwickeln? Das ist ja genau das worum es geht und warum es solche Problem bei Flac nicht gibt.
Dazu siehe weiter unten (x).
Völliger Bullshit. Als wenn morgen alle Daten wertlos sind und Stereo out sei. Klar, morgen wirft man alles weg.
Ein Bekannter hat sich jetzt noch einen Plattenspieler gekauft und kauft sich wieder Schallplatten.Was du machst, interessiert keinen. Es geht rein um die Frage der Langzeitarchivierung und da ist ein proprietäres Format, das nicht standardisiert ist, nicht wirklich brauchbar. Nur die Tatsache, dass Apple eine große Firma ist, Quicktime sehr verbreitet und wir hier von lossless sprechen, entschärft das Problem etwas. Optimal ist das aber nicht.
Bei Abwärtskompatibilität habe ich gegrinst, da das überhaupt nicht so pauschal stimmt (siehe div. OS X Versionen bzgl. Programmen). Aber es geht ja um Formate.
So, auf welche selbstentwickelten Formate von Apple beziehst du denn die Aussage? Nur zur Info: AAC ist nicht von Apple (und AAC ist auch standardisiert). Wer garantiert denn, das Apple nicht ALAC fallen lässt, wenn ein geeigneter lossless Codec mal zum ISO-Standard erhoben wird?
Aber das spielt keine Rolle: Denn sich auf einen nicht standardisierten und proprietären Codec zu verlassen/hoffen ist alles andere als optimal im Vergleich zu einem Codec der OpenSource ist und/oder standardisiert vorliegt.
Womit du rechnest, ist keine gute Ausgangsbasis.
Das steht auch bei Philips, das DivX geht. Von ALAC steht nirgends etwas.
Philips DVD player DVP5200 DivX
DVP5200/12
http://www.p4c.philips.com/cgi-bin/dcbint/cpindex.pl?ctn=DVP5200/12&scy=de&slg=DEU
Ich habe oben den DVP520/00 verlinkt.
(x)
Also nochmal:
Wo kann man sich die Specs anschauen, damit man einen Encoder selber erstellen kann?
Wie soll dann ohne Specs oder SourceCode sich jemand dazu bequemen, einen Encoder dafür zu erstellen, um z.B. ALAC ohne ReverseEngineering unter Linux zu nutzen?
Bei Flac (im Gegensatz zu deiner falschen Behauptung) alles problemlos - auch unter Mac OS X, solange man kein iTunes nutzt (XLD, Max, VLC, Play, ...).
AAC ist nicht ALAC. Die Formate haben überhaupt nichts miteinander zu tun. ALAC ist auch kein MPEG4-Audio.
http://www.audiohq.de/index.php?showtopic=1407
Eben. Danke schön sagt Dieter Nuhr. Soviel Bullshit wie du hier verzapft hast, habe ich glaube ich noch nie gelesen.
An deiner Stelle wäre ich einfach mal ganz still!
AAC (lossy) != ALAC (lossless)
Zuletzt bearbeitet:
Um nochmal auf die Ausgangsfrage zurückzukommen:
ALAC spielt ausserhalb der Apple-Welt so gut wie keine Rolle. Wäre iPod, iTunes & Co nicht so erfolgreich, würde kein Hahn nach ALAC krähen.
Ausserhalb der Apple-Welt, insbesondere dort wo es kein Quicktime gibt, ist die Nutzung von ALAC problematisch und wenn überhaupt nur wegen Reengineering möglich.
Flac hingegen ist so eine Art Quasi-Standard bei lossless geworden. Wenn lossless ausserhalb der Apple-Welt unterstützt wird, dann ist das meist Flac. Hier gibt es eine unvollständige Liste (Hard- und Software): http://wiki.hydrogenaudio.org/index.php?title=FLAC#Hardware_and_software_that_support_FLAC Mit Rockbox (Firmware) kann es auch der iPod. Hier gibt es eine weitere Liste, in der auch Bands aufgeführt sind, die Flac anbieten (darunter u.a. Metallica und Pearl Jam): http://flac.sourceforge.net/links.html
Weitere Liste: http://flac.sourceforge.net/download.html#extras
Flac ist OpenSource und dokumentiert und es kann somit jeder nutzen und eignet sich somit auch für Langzeitarchivierung. Unter Mac OS X kann man natürlich ebenfalls problemlos Flac nutzen, nur eben unter iTunes ist es problematisch (gilt auch für die Windowsversion, die vielleicht bzgl. Flac noch schelchter da steht?). In iTunes geht es leider nur über Tricks, da Apple bisher Flac nicht unterstützt.
Ein wenig Hoffnung habe ich aber, dass sich das in Zukunft vielleicht mal ändert, nachdem das neue Quicktime mit SnowLeoard raus ist. Dann wäre das Problem gelöst und man könnte mit Flac einen lossless Codec nutzen, der überall genutzt werden kann, wenn man Flac implementiert, denn Flac ist frei verfügbar und in seiner Nutzung nicht durch Softwarepatente beschränkt.
ALAC spielt ausserhalb der Apple-Welt so gut wie keine Rolle. Wäre iPod, iTunes & Co nicht so erfolgreich, würde kein Hahn nach ALAC krähen.
Ausserhalb der Apple-Welt, insbesondere dort wo es kein Quicktime gibt, ist die Nutzung von ALAC problematisch und wenn überhaupt nur wegen Reengineering möglich.
Flac hingegen ist so eine Art Quasi-Standard bei lossless geworden. Wenn lossless ausserhalb der Apple-Welt unterstützt wird, dann ist das meist Flac. Hier gibt es eine unvollständige Liste (Hard- und Software): http://wiki.hydrogenaudio.org/index.php?title=FLAC#Hardware_and_software_that_support_FLAC Mit Rockbox (Firmware) kann es auch der iPod. Hier gibt es eine weitere Liste, in der auch Bands aufgeführt sind, die Flac anbieten (darunter u.a. Metallica und Pearl Jam): http://flac.sourceforge.net/links.html
Weitere Liste: http://flac.sourceforge.net/download.html#extras
Flac ist OpenSource und dokumentiert und es kann somit jeder nutzen und eignet sich somit auch für Langzeitarchivierung. Unter Mac OS X kann man natürlich ebenfalls problemlos Flac nutzen, nur eben unter iTunes ist es problematisch (gilt auch für die Windowsversion, die vielleicht bzgl. Flac noch schelchter da steht?). In iTunes geht es leider nur über Tricks, da Apple bisher Flac nicht unterstützt.
Ein wenig Hoffnung habe ich aber, dass sich das in Zukunft vielleicht mal ändert, nachdem das neue Quicktime mit SnowLeoard raus ist. Dann wäre das Problem gelöst und man könnte mit Flac einen lossless Codec nutzen, der überall genutzt werden kann, wenn man Flac implementiert, denn Flac ist frei verfügbar und in seiner Nutzung nicht durch Softwarepatente beschränkt.
Zuletzt bearbeitet:
2003-2024 Apfeltalk | Made on a Mac