On Mon, 25 Mar 2013 09:47:36 +0100 Fabian Greffrath <fab...@greffrath.com> wrote:
> This commit refers to the frontend code and does not touch libfaad > itself. .... > > I am not that sure anymore. It seems that the library is fine to play > gapless and that its the frontends that need to get patched in order > to cope with this. But this is only a guess, we are still lacking a > patch against libfaad to confirm this... > > - Fabian Thanks for looking at the Rockbox implementation. Meanwhile the "official" faad binary itself surely would not be one of the frontends which doesn't use libfaad properly? I just built faad and libfaad from most recent source (now I see the bug tracker is at sourceforge, which is why I couldn't find it at audiocoding.com) and I get the same result: I make gapless m4a with neroAacEnc: to avoid any possible imperfect player's use of libfaad I decode to wav and play the wavs a) with 'mplayer2 -gapless-audio' and b) on my player running Rockbox: decode with neroaacdec: the wavs play gaplessly. decode with faad: there is a gap inserted. decode with win32 application foobar2000: the wavs play gaplessly. I repeat the exercise, this time making the encode with fdkaac instead of nero: The result is identical: wavs produced by faad have a gap inserted. wavs produced by <another_decoder> play as intended. I'm still concluding that faad/libfaad can only correctly decode gapless files if they are produced by faac, which doesn't seem to match the package description of "FAAD2 correctly decodes all MPEG-4 and MPEG-2 MAIN, LOW, LTP, LD and ER object type AAC files." I hope I haven't completely misunderstood this, and I appreciate that any fix, if even possible, might not be very likely but thank you for taking the trouble to look into it regards Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
