Correction: Audacity was partly to blame, I have discovered it truncates data from the end of mp3 files, I have started examining my test results with another sound editor since (nch wavepad) which does show that your patch (flush-lame) does indeed correct the issue with loss of data at the end of the file (and confirms that the current 1.1.0 does indeed cut the end off of mp3 files). So your fix does work.
Note that I have tested it as encode_flush as opposed to encode_flush_nogap. I see discussion of removing encode_flush... I would leave it in for the option to be there for easy modification of the code in future. So now if we can get eat_blank to eat blank from the beginning of a file I'll be all set! May 3, 2013 02:32:20 PM, [email protected] wrote: >Lame is to blame, I tested the patch that was offered for LS (flush-lame >branch) >and it did not resolve the issue, so I did some additional testing with Lame >alone, >and it is the source of the lost data at the end of files and the excess >padding at >the beginning. (It does not truncate files when given mp3 input but does when >given raw pcm or wav file input. > >Thanks for pointing me at that FAQ, as #'s 2 and 3 there indicate they have >had problems with this. They are in fact padding with 2358 samples of silence >at the beginning of a file - well over the amounts described in the FAQ. >I will modify lame's encoder.h as suggested to see what I get to reduce the >excessive padding at the beginning of a file. > >Interestingly, FAQ #3 there suggests they are padding the end of a file with >silence to prevent truncation of data - clearly this is not working, as data >is lost. > >So I am going to work with the lame source to see if I can resolve these >issues. > >Note, as I mentioned earlier, in trying to work around this issue with lame, >I discovered that liquidsoap's eat_blank is ignoring at_beginning and still >eats >blank data at the end of a file, in addition, it refuses to eat blank data at >the >beginning of a file. I have not looked at this in the liquidsoap source yet, >as >I have been preoccupied with the lame issues. > > > >Apr 29, 2013 04:18:38 AM, [email protected] wrote: >>Hi, >> >>There are two issues here. >> >>1. For the beginning, I don't see anything obvious on our side, but >>lame's doc mentions some mandatory padding ( >>http://lame.sourceforge.net/tech-FAQ.txt ) which might explain the >>problem? >> >>2. For the end, we effectively did not flush the encoder. I commited a >>patch ( https://github.com/savonet/liquidsoap/pull/68 ), which should >>hopefully integrated soon. >> >>++ >> >>Sam. >> > ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
