Könntest du die "kaputte" mp3 kleinschneiden, so daß der Fehler noch ausgelöst wird und mir dann mailen?
Leider nein. Wenn ich mal Zeit habe will ich aber von Win-API auf wxwidgets umstellen und dann wird es auch Linux binaries geben. Doch mache ich mir noch zur Zeit Gedanken, wie ich am sinnvollsten das ganze Interface machen kann, um redundanten Code zu sparen. Ein Gehacke wie zur Zeit will ich mir sparen...
AFAIK stimmt das nicht. MLP ist nicht immer lossless. Sobald eine bestimmte bitrate überstritten wird, wird es verlustbehaftet. (Ich weiß, daß das marketing was anderes sagt.)
Kannst du mal eine andere mp3 Datei probieren? Ich habe die Vermutung, daß du die mp3 Datei nicht selbst erstellt hast...probier es mal mit einer sauber kodierten Datei.
Dennoch interessant, daß es dieses Mal nicht abgestürzt ist. Es könnte dennoch am decoder liegen, wenn der mit Schrott gefüttert wird.
Bekommst du mit (sauberer) mp3 Quelle hac3 zum Absturz? Wenn mit kaputter mp3 Datei, wäre es evtl auch interessant, um mpalib etwas robuster zu machen...
Geht mp3->wav? Geht das mit der Datei mit einer älteren hac3 Version? Es könnt auch an einer kaputten mp3 Datei liegen, daß der decoder dbei hoppst geht.
So, endlich ist es soweit. Dank LigH's großer Hilfe konnten nun viele kritische bugs eliminiert werden. Da als wichtigste kritische Funktion nach wie vor nicht delay Kompensation implementiert ist, hat das Archiv das Paßwort "nodelay".
Änderungen:
- dumb mode funkt nun so, wie man es erwartet - ohne daß der encoder aufgerufen wird (peinlich peinlich)
- diverse kritische bugs, die zu segfaults führen, in HeadAC3he und auch ssrc gefixt
- Abbrechen sollte nun auch viel schneller gehen
- mehr Fehlerprävention, bzw vernünftige Abbrüche gewährleisten bei Fehler
- komplettes Paket mit neuen mingw/gcc 3.4.4 kompiliert
Im Archiv befinden sich "alle" aktuellen dlls.
So, nach diesen Tag brauche ich wieder was Pause...Mann war das ätzend.:mad:
Tja, ist doch mehr zu tun als ich dachte. Vor allem hasse ich schwer reproduzierbare bugs. :-/ Alles weitere erst mal per email.
OK, dieses Mal habe ich den bug gefunden, der ds Prob bei dir macht. Naja, auch nicht schlecht. Gleich mal ein paar kritische bugs eliminiert. Komisch, daß das noch keinem vorher aufgefallen war...
Und?
Nö, frames ist nicht zwangsläufig auf Bild bezogen. Frame = Rahmen, also eine Einheit und digitale komprimierte Audiodaten werden auch in frames übermittelt. Bei dvd-ac3 geschieht das normalerweise in 31,25fps (unabhängig Bild fps).
Und außerdem: Eine Tonspur hat keine Bilder - also auch keine Bildwiederholrate!
[klugscheiß] fps=frames per second und das gibt es gewöhnlicherweise durchaus bei komprimierten Audio Daten, allerdings sind die Werte etwas anders... 
[/klugscheiß]
Aargh, ok, probier bitte nochmal mit der Version, die grad raus ging. (BTW, ich guck etwa alle 20 Minuten nach mail... :D)
Oh, hast du meine email nicht bekommen? Ich hatte dir die a3 geschickt, damit du mal testen konntest, ob ich den bug elimiert habe, oder nicht.
Oder ein wenig gedulden. 0.25a3 hat wieder "alle" dlls drin. Warte nur noch auf das OK bzgl bug von LigH. 
Hmm, werde ich mir mal angucken. Danke für den report.
Schick mir mal bitte deine INI und auch die Vorbis dlls, die du verwendest. Ich denke es liegt an den vorbis dlls. Woher hast du diese? Aus welchem Archiv hast du die hVorbis.dll?
Stürtzt es auch bei anderen targets ab?
Probier es mit dem neuesten HeadAC3he v0.25a2. Vorher ging kein upsampling. Guck ein paar threads tiefer. DA findest du auch die passende ssrc dll.
Ich hatte gerade mit nem Sony schlechte Erfahrungen gemacht, allerdings war das wohl auch ein recht preisgünstiges Gerät und dazu auch noch Doppelkassettendeck.
Mein Dad hatte mal (mehr durch Glück, als gezielt) ein recht nettes Deck von Philips gekauft, welches 3 Köpfe hat, so daß die Aufnahme direkt begutachtet werden kann und man dadurch BIAS recht gut einstellen kann. Außerdem hat es MPX (was ich allerdings nie brauchte, da ich nicht von Radio aufnehme) und Dolby HX-Pro B/C und gewiß noch andere Spielereien, von denen ich null Ahnung habe. Ja, damit konnte man Tapes erzeugen, die der CD in nicht viel nachstanden. Nur mochte das Teil eine spezielle Sony METAL Kassettentyp nicht, dh die konnten nicht richtig bespielt werden. Miot anderen Fabrikten ging das ohne Probs. Naja, die "gute" alte Zeit - ohne DRM und so Seuchen.
Dolby B bringt meines Erachtens sehr wenig, da ist Dolby C schon sehr viel besser. Aber Recht hast du natürlich, daß man eine entsprechend kodierte Aufnahme auch richtig dekodieren sollte.
Kriegt man nicht gebraucht ein passables Deck für wenig EUR? (Hattest du die Tapes selbst aufgenommen und dabie Dolby benutzt? Dann solltest du am besten dasselbe Modell kaufen, weil insbesondere bei der C Variante sich die Decks unterschieden können. Merke ich hier ganz stark.)
Solange er nur abspielen will und nichts per Dolby aufgenommen hat, braucht er es auch nicht... Original Kassetten sind allerdings wohl meist mit Dolby NR B kodiert.
Ich bin froh, wenn ich etwas feedback bekomme - positives umso besser.
Ich schrieb auch, daß die Längen anzupassen wären, darum mal die specs vom header angucken. AFAIK sind an drei Stellen (WAVE, fmt und data chunk) die Werte anzupassen.
Zur Not mittels Hexeditor einen passenden WAVEheader dranbasteln. (Man erstelle eine funktionierende Datei und kopiere diesen Header und korrigiere die Längenangaben entsprechend. Man sollte natürlich wissen, wie ein solcher Header aufgebaut ist und mit Hexzahlen klarkommen...)
