Ist der Lame Mp3-Codec ein schwieriger oder einfacher Code? Ist ein Universitätsstudium für solch eine Aufgabe(Codecprogrammierung) zwingend vonnöten? Mit Begründung. Frage richtet sich natürlich nur an die, die sich damit beschäftigt haben.
:
Gesperrt durch Admin
Dirk Osterhagen schrieb: > Ist der Lame Mp3-Codec ein schwieriger oder einfacher Code? Keine Ahnung, nie reingeschaut. Wird wohl deutlich über dem Level von Hello World liegen. > Ist ein > Universitätsstudium für solch eine Aufgabe(Codecprogrammierung) zwingend > vonnöten? Mit Begründung. Nein. Begründung: ganz einfach, alles was Du an der Uni lernst kannst Du auch ohne Studium lernen (uhhh, muss man so triviale Tatsachen wirklich explizit aussprechen heututage?). Die theoretischen Grundlagen von MP3 (psychoakustisches Modell) sind allerdings schon happig.
>Frage richtet sich natürlich nur an die, die sich damit beschäftigt haben. >Keine Ahnung, nie reingeschaut. Ohne Worte
Ich glaube du wirst hier wenige Leute finden, die sich explizit mit dem lame MP3 Codec beschäftigt haben. Ich habe mich auch noch nicht damit beschäftigt. Ich habe mir schonmal verschiedene Teile von ffmpeg, mencoder und mplayer angeschaut. Grundsätzlich würde ich die Frage in 2 Teile aufteilen: - MP3 Codec generell - Lame Codec Zu MP3 generell ist einiges an theorethischen Wissen erforderlich, aber nichts was man sich nicht innerhalb von ein paar Wochen im Netz zusammenlesen kann. Bei Wikipedia anfangen und dann einfach den Links folgen Zum lame Codec würde ich sagen ist ein gutes Verständnis von C, die Fähigkeit sich in komplexen Code zurecht zu finden und das wissen aus dem oberen Teil wichtig. Ich würde sagen ein erfahrener Programmierer hat hier deutlich bessere Chancen als ein frischer Bachelor / Master.
Meistens wird in den Standards nur das Dekodieren des Datenstroms beschrieben, und nicht wie man den encodierten Datenstrom herzustellen hat. Ich kenne den lame-Code nicht und man benötigt auch nicht zwingend ein Hochschulstudium um so etwas zu schreiben, aber die Grundlagen wie FFT, DTC, Quantisierung, Huffman und das hinter dem Codec liegende psychoakustische Modell lernt man auch nicht unbedingt bei der Sendung mit der Maus... Fundierte Kenntnisse in der digitalen Signalverarbeitung sollte man schon mitbringen. Und um einen konkurrenzfähigen Codec zu schreiben sollte der dann am Ende auch noch schnell sein. Wobei ich persönlich denke, dass das dann das kleinere Problem ist.
Dirk Osterhagen schrieb: >>Frage richtet sich natürlich nur an die, die sich damit beschäftigt > haben. > >>Keine Ahnung, nie reingeschaut. > > Ohne Worte ;-) Du hast nicht verstanden was ich sagen wollte. Ob das ein komplizierter oder einfacher Code ist hängt extrem vom Betrachter ab - und der konkreten Definition von kompliziert/einfach, dazu kann man also keine irgendwie sinnvolle Aussage treffen. Was man beantworten kann ist die Frage nach der Notwendigkeit des Uni-Studiums.
Andersherum, WAS zum Lame-Code willst du wissen? Fang an zu suchen/verstehen, wenns klemmt frag' nach.
Dirk Osterhagen schrieb: > Ist ein > Universitätsstudium für solch eine Aufgabe(Codecprogrammierung) zwingend > vonnöten? Mit Begründung. Was ist "Codecprogrammierung"? Den Decoder dem Standard nachprogrammieren? Dafür nicht. Selber einen guten Encoder entwickeln? Dafür schon eher.
Nun, ich habe mich mit dem Quellkode beschäftigt mit dem Ziel, die lame_enc.dll (32 und 64 bit) kleinzukriegen. 1 MByte kann nicht sein, SOO kompliziert ist LAME (deutsch: lahm) nun auch wieder nicht. Ich habe es nun auf 120 KByte runterbekommen. Immer noch eine schwere Echse, wenn man ein Kilobyte mit einem Kilogramm aufwiegt. Ich kann erst mal nur vage vermuten, dass die Compilereinstellung O1 (Größe) gegen der Originaleinstellung O2 (Geschwindigkeit) den Löwenanteil macht. Was die DLL dann um ein paar Promille langsamer macht spielt heutzutage keine Rolle mehr. Aus Sicht eines C(++)-Programmierers ist lame_enc.dll ein gutes Beispiel dafür, wie man NICHT programmiert: Das Programm ist um ein Gottobjekt (äh-struct) herumgestrickt, hat hunderte API-Aufrufe, und kann kein Unicode in Dateinamen, versagt also bei exotischen Dateinamen. Normalerweise sollte eine DLL sich nicht wie ein Fremdkörper verhalten (bspw. _stdcall statt _cdecl) und einfach zu verwenden sein (bspw. "rundll32 lame_enc.dll,Encode *.wav" - fertig). Das Totschlag-Argument "Linux-Background" ist keine Entschuldigung für schlechte, fremdkörperartige Software. Der fachliche Teil (also der Kern des MP3-Kodierers) ist erwartungsgemäß schwierig zu verstehen. Immerhin ist lame nicht auf Geschwindigkeits-Optimierung sondern auf Verständlichkeit solcher Routinen optimiert (angeblich). Zurück zur Ausgangsfrage: Was reizt daran, eine Codec neu zu schreiben? Wenn sowas funktioniert ist und bleibt man heilfroh und rührt man das nicht an. Nicht ohne wirklich triftigen Grund. Besser komprimierende Codecs gibt es schon lange, bspw. Vorbis. Der ist aber auch deutlich größer.
Henrik Haftmann schrieb: > Besser komprimierende > Codecs gibt es schon lange, bspw. Vorbis. Der ist aber auch deutlich > größer. Wobei Vorbis auch schon wieder hoffnungslos veraltet ist. Aktuell ist Opus. Damit so ein CODEC schnell ist, muss er die DSP-Befehlserweiterungen (SIMD) der jeweiligen Architektur verwenden (MMX, SSE bei INTeL, bei ARM heisst das DSP). Vielleicht kannst du so einen CODEC auf RISC-V portieren, falls das noch niemand gemacht hat. Ansonsten: CODECs kommen und gehen. Und sind gewöhnlich irgendwo in den Tiefen des Systems verborgen. Gestalte lieber einen coolen Skin für einen Multimedia-Player, das rockt viel mehr.
10 Jahre sollte lange genug sein den Code zu verstehen.
Johannes S. schrieb: > 10 Jahre sollte lange genug sein den Code zu verstehen. Ist sicher eine gute Schätzung. MMX ist weniger abstrakt, und hat trotzdem seine Eingewöhnungszeit gebraucht. Wenn man die Artikel und Bücher von Alfred Aho gelesen bzw. durchgearbeitet hat, ist man sicher auch eher im grünen Bereich. https://de.wikipedia.org/wiki/Alfred_V._Aho Ein Universitätsstudium braucht man vielleicht nicht - aber eine Universität mit entsprechender Literatur in der Bib wäre schon ganz gut. Außerdem kann man da auch Leute zum Fragen finden mit etwas Glück.
Thread beobachten
Seitenaufteilung abschalten