Wenn du den Quellcode vom Lame Mp3-Codec kennst lies hier

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.

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.