Oddly enough, using the smart_crossfade operator instead of the simple one the problem disappears even with conservative=false...
So, if the FLAC decoder induces a wrong remainining time why is it playing back correctly using smart_crossfade? It looks like the problem is buried inside the low level cross() operator which is used by the simple crossfade (and not by smart_crossfade)... Anyway, I'm a bit reluctant to the usage of smart_crossfade because it's quite costly on the cpu given the features that I don't really need.. So, it would be nice to have simple crossfade work with FLACs, too... Where can I find more information about the add_oblivious_decoder() function? I couldn't find any useful information in the official doc... Cheers, Henry On 06.07.2010 21:31, David Baelde wrote: > It could be that the external FLAC decoder induces bad remaining time > estimations (those things vary with file format, notably header and > footer sizes, but also the amount of buffering the external decoder > does). You could try registering a FLAC decoder with > add_oblivious_decoder() which does not make any guess regarding > duration, and only reports a (correct) duration at the end of the file > when all remaining data has been decoded (the amount of data that is > prebuffered can be tweaked, which allows to get the remaining time > estimation more or less early). ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
