Hey! 2011/12/2 Martin Hamant <[email protected]> > > > > Le 02/12/2011 14:15, Romain Beauxis a écrit : > >> Hi, >> >> 2011/12/2 Martin Hamant<[email protected]>: >>> >>> >>> Le 01/12/2011 19:24, David Baelde a écrit : >>> >>>> Hi guys, >>>> >>>> I listened to the two files. Sometimes I feel like I can hear some >>>> artifacts, but it's really slight; I'm not sure I could tell them >>>> apart in a blind test. Anyway, I'm no expert in hearing compression >>>> artifacts. >>> >>> I'm no expert either, but I have good hears (I don't say you haven't ;) ) >>> and I can tell for sure the sound is affected, much more as it should be for >>> this bitrate. >>> But see below I have done more tests. >>> >>> >>>> I'm not sure where to go from here. It would be interesting to check >>>> what parameters really end up being passed to liblame with the two >>>> tools. Sometimes, an interface might do some adjustment on parameters >>>> to make things sound better. >>> >>> >>>> Otherwise, if you don't want to dig into the source code of audacity >>>> (for liquidsoap, you can ask us the details) you can just try to raise >>>> a little bit the quality settings. >>>> >>> The thing is, even exporting with lame parameter -q9 ("Disables almost all >>> algorithms including psy-model. Poor quality."), I can't get it as worse as >>> the LS's one. >>> I would like to find a parameter in lame that would reproduce the noise I >>> can hear, but I can't find one to make it worse :D >>> >>> More seriously, I done some more testing. I tested a compress to 96Kbit/s >>> and compared it with the 128Kbit/s from liquidsoap. The conclusion is the >>> artefacts I hear in the 96k one is for sure not the kind of the >>> artefacts/noise in LS one. >>> the 96k bitrate raise some "birdies" in the sound when the LS file get some >>> "noise"/tremolo in low frequencies. HF are not so much affected. >>> >>> For me, there is little chance that this quality issue to be related to >>> libmp3lame. So the question would be, may LS apply some kind of processing >>> on the file before or after the encoding step ? >> >> No we don't. Actually, since you are using FLAC as input, you can >> assume that PCM data fed to lame is the exact original data. >> >> However, I'v had a look at ocaml-lame parameters and I think this guy, >> which we do not use, might be a good candidate: >> http://liquidsoap.fm/modules/ocaml-lame/Lame.html#VALset_quality > > Like I've specified, this quality setting doesn't affect the sound in the way > I have observed with liquidsoap. > What I can say for sure is even q=9 (worst) from lame command-line tool is > far better than current liquidsoap mp3 output thru libmp3lame :/ > > The more surprising in what I can hear (and see on spectrograms comparing > the two resulting files) is that rumble in the end/low-end frequencies.
So, I have just commited some changes in HG's default branch, which bring two new parameters to the %mp3 encoder: * internal_quality: this is the parameter I mentioned earlier * stereo_mode: set stereo, joint_stereo or default mode. Default values for those parameters are those recommended by liblame. It would be very nice if you could test and report what quality you observe with those changes in the encoder. Thanks, Romain ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Savonet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/savonet-users
