Re: [MP3 ENCODER] Interesting high quality settings and possible bug
> Hello, > > Hrmm... that is an interesting idea. I completely hadn't thought of this. Does this actually take away bits from being used to encode the audio frame? If so then what is the real use of this switch? I had thought this switch would help to prevent the mp3 from being possibly corrupted by being transferred over and over again. Not that this really happens often but I thought why not. If however this switch really isn't that useful and it takes bits away from being used to encode the audio then I will stop using it. Currently I haven't noticed any degredation in sound just through normal listening tests, although I haven't looked into the matter further. I will do some testing and see if encoding without this switch seems to have any impact. -p is for adding a crc check to every frame. It does not prevents any corruption of the bitstream, it just help to detect if it has been corrupted. As it uses bits for the crc, it will lower (a little) the quality of CBR encoding, and will higher the filesize of vbr. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] mobile phone: [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Interesting high quality settings and possible bug
Gargos Chode wrote about the -k switch: > > Hrmm... that is an interesting idea. I completely hadn't thought of this. > Does this actually take away bits from being used to encode the audio > frame? If so then what is the real use of this switch? I had thought > this switch would help to prevent the mp3 from being possibly corrupted by > being transferred over and over again. Not that this really happens often > but I thought why not. If however this switch really isn't that useful > and it takes bits away from being used to encode the audio then I will > stop using it. Currently I haven't noticed any degredation in sound just > through normal listening tests, although I haven't looked into the matter > further. I will do some testing and see if encoding without this switch > seems to have any impact. > It takes something around 612 bits/s. This is less 0.5% for 128 kbps, even less for higher bit rates. It becomes interesting for bitrates in the range from 8...24 kbps. -- Frank Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Interesting high quality settings and possible bug
Hello, Hrmm... that is an interesting idea. I completely hadn't thought of this. Does this actually take away bits from being used to encode the audio frame? If so then what is the real use of this switch? I had thought this switch would help to prevent the mp3 from being possibly corrupted by being transferred over and over again. Not that this really happens often but I thought why not. If however this switch really isn't that useful and it takes bits away from being used to encode the audio then I will stop using it. Currently I haven't noticed any degredation in sound just through normal listening tests, although I haven't looked into the matter further. I will do some testing and see if encoding without this switch seems to have any impact. Dibrom -- On Thu, 5 Oct 2000 09:54:35 Yog Sothoth wrote: > if lame writes a 16 bit crc for every frame (using -p switch), >doesn't that mean there are 16 less bits for sound data for each >frame? couldn't that affect sound quality? is this getting >carried away a little too much? :) > >On Thu, Oct 05, 2000 at 09:30:23PM +1300, Ross Levis wrote: >> -p & -F will have no effect on sound quality. I have had mixed results with >nspsytune. >> >> Ross. > >-- >Michael Horan III > Get your FREE Email and Voicemail at Lycos Communications at http://comm.lycos.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Interesting high quality settings and possible bug
if lame writes a 16 bit crc for every frame (using -p switch), doesn't that mean there are 16 less bits for sound data for each frame? couldn't that affect sound quality? is this getting carried away a little too much? :) On Thu, Oct 05, 2000 at 09:30:23PM +1300, Ross Levis wrote: > -p & -F will have no effect on sound quality. I have had mixed results with >nspsytune. > > Ross. -- Michael Horan III PGP signature
Re: [MP3 ENCODER] Interesting high quality settings and possible bug
Hello, On Thu, 05 Oct 2000 20:02:11 Naoki Shibata wrote: > First, one should not specify "--athlower -35". This may significantly >degrade sound quality. > > I always used -q1 while tuning --nspsytune. I think -q1 doesn't >degrade sound quality so much with --nspsytune. > > Theoretically, -X doesn't affect sound quality in VBR mode. > I must say that pretty much all of my findings are different. With these particular settings --athlower up to a certain point does not seem to have much of an impact at all on sound quality... that threshold seems to be around -35. Over -35 ( -40 for example), I do begin to notice audible sound degredation although even at this level it seems to be low. The quality degredation seems to take place at an exponential rate though as the number is increased. I have encoded quite a few albums so far with --athlower -35 and it seems to be keeping the quality pretty high while still keeping the file size lower. However, if there is a better way to go about doing this (I did try using a lower value for -V and -q but lowering -V seems to sound worse, and -q seems to have very little effect) then I would like to know about it. -q1 seems to degrade the sound quality fairly significantly on a few different test clips, fatboy.wav in particular. On most songs it doesn't seem to degrade the quality all that much but I have heard it a few times, and because of this (and because of the massive speed hit when using it with these settings... ~3.5x realtime to ~.8x realtime) and the negligible impact in file size with these settings, I would rather be safe so I choose not to use it. I have noticed that with -V1 -mj -b128, -q1 seems to help quite a bit with file size, but again here I have heard quality degredation. Theoretically maybe -X isnt supposed to do anything but I am 100% that this is not the case. Simply chosing different -X modes has a significant effect on file size, as well as quality size. Fatboy.wav encoded without -X3 sounds MUCH different than with -X3. If -X3 truly is not supposed to have any impact on vbr then perhaps this is a bug or something, I do not know. Dibrom > >-- >Naoki Shibata e-mail: [EMAIL PROTECTED] > >-- >MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) > Get your FREE Email and Voicemail at Lycos Communications at http://comm.lycos.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Interesting high quality settings and possible bug
-- On Thu, 05 Oct 2000 21:30:23 Ross Levis wrote: >Gargos Chode wrote: > >> -V1 -mj -b128 -q2 -d -p -k -F --nspsytune --athlower -35 -X3. > >Some thoughts: > >-p & -F will have no effect on sound quality. I have had mixed results with >nspsytune. -X2 & X3 both produce massively larger average bitrates than all the >others. I've never played with -d. Can someone tell me if allowing channels to have >different blocktypes has any bad side effects? ie. ISO or decoder compatibility? > >Ross. > > >-- >MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) > Hello, I know that -p and -F don't have any effect on sound quality, infact I stopped using -F cause alot music I have has hidden parts in songs and the drop to 32kbps was nice there for space saving reasons. As for -X2 and -X3 the fact that they are the slowest and usually produce files with much higher bitrates is probably the reason they also seem to sound so good. That is basically why I am using --nspsytune and --athlower, to get that file size to come back down to a reasonable level. It might make more sense to just use a different set of switches which will produce files around those bitrates in the first place instead of making large files and trying to squeeze them back down, but from what I have heard, it actually sounds better the latter way. In some cases I have actually seen these settings produce smaller files than -V1 -mj -h -b128, and they still sound better. On average, it seems to produce files an average of 20kbps at least for most of the music I listen to. H! owever, with certain sound clips, particularly ones with very fast transients and noise like sound overlayed upon strings or melodic sounds, the bitrate seems to be much much higher than normal. One clip I have actually reaches up to 290kbps. Im thinking something about that particular kind of sound, or the production used on those albums, is tripping up the encoder and forcing it to use too many bits. Either that or those pieces are just extremely hard to encode without producing alot of distortion. For ISO compatibility and decoder compatibility, I haven't seemed to notice any difference at all. For that matter in most cases I dont notice a difference in filesize or sound quality either, so I'm not really sure that its even doing anything, but it at least sounds good in theory. Dibrom Get your FREE Email and Voicemail at Lycos Communications at http://comm.lycos.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Interesting high quality settings and possible bug
Ross> Gargos Chode wrote: Ross> Ross> > -V1 -mj -b128 -q2 -d -p -k -F --nspsytune --athlower -35 -X3. Ross> Ross> Some thoughts: Ross> Ross> -p & -F will have no effect on sound quality. I have had mixed results with nspsytune. -X2 & X3 both produce massively larger average bitrates than all the others. I've never played with -d. Can someone tell me if allowing channels to have different blocktypes has any bad side effects? ie. ISO or decoder compatibility? First, one should not specify "--athlower -35". This may significantly degrade sound quality. I always used -q1 while tuning --nspsytune. I think -q1 doesn't degrade sound quality so much with --nspsytune. Theoretically, -X doesn't affect sound quality in VBR mode. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Interesting high quality settings and possible bug
Gargos Chode wrote: > -V1 -mj -b128 -q2 -d -p -k -F --nspsytune --athlower -35 -X3. Some thoughts: -p & -F will have no effect on sound quality. I have had mixed results with nspsytune. -X2 & X3 both produce massively larger average bitrates than all the others. I've never played with -d. Can someone tell me if allowing channels to have different blocktypes has any bad side effects? ie. ISO or decoder compatibility? Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Interesting high quality settings and possible bug
>At these types of average bitrates, I think you might be better off >with CBR instead of VBR. This is because with an average bitrate >230kbs, you only need an extra 90kbs to go up to 320kbs. 90kbs >is only 40% of the average frame size - these types of fluctuations >are easily handled by the bitreservoir in CBR mode. >(it can handle such a fluctuation in 25% of the frames) > >VBR is more usefull at lower bitrates: take an average bitrate of >128kbs, where you need an extra 250% of the average frame size to make >it up to 320kbs. CBR mode can handle such a fluctuation, but for only >about 4% of the frames. > Well I actually have thought of using just straight CBR but in most of the cases that I have tested these particular VBR settings seem to perform better. For example, when encoding fatboy.wav with these vbr settings the file size is around 224kbps or something, i dont recall exactly now when I encode fatboy.wav with lame -b256 -mj -q2 --nspsytune -X3 (and also without --nspsytune) the CBR file clearly has more noise in the background than VBR file... for me to get a CBR that sounds as good I have to bump up the bitrate to 256kbps. Granted, 224 to 256 isnt that big of a difference, but if it sounds better at a lower bitrate then why not use it? Earlier I remember there being some talk about --nspsytune spending too many bits on tonal parts of audio clips... i think that if this hasnt been resolved, that when it is, it should probably result in even smaller files with possibly the same level of quality. I have noticed that on most of my music, the more melodic stuff is us! ually what ends up being encoded at bitrates of 250kbps and above. If the effeciency of --nspsytune in those cases can be improved them filesize should become less of an issue, and will make these particular VBR settings more appealing. > >The last time I saw this error, it turned out to be because >the user was overclocking his system and it was unstable. >If that is not the problem, then you need a version of LAME >compiled with debugging information turned on. LAME will >then probably stop before MAX_HEADER_BUF overflows, with a different, >more informative message. Did you compile lame yourself? > >Mark >-- >MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) > I am 100% sure this is not the case. Although I will admit that my system is overclocked I have run extremely extensive tests (prime95 for days, etc) and I usually have uptimes of several weeks, while running graphics programs, games, running an ftp server, encoding mp3s, etc. Lame is the only thing affected, and only when using these settings. As for the version I am using, it is here: http://www.chat.ru/~dkutsanov/lame387mmx.zip It seems to work great other than that particular error every once in awhile... usually if I go back and reencode the song it will work ok, although there was one particular song (I'll try to find which one it was) where it took 5 tried before it would fully encode. Thats about it... although I am kinda hoping to get some more comments on the particular settings themselves... One thing I am kinda wondering about is how the whole -X switch fits into the equation... I have tried every -X switch with those settings and -X2 and -X3 are the only ones which seemed to encode various test files without errors... is there something special about how those relate to the other settings? Also, the reason I use --nspsytune is because it usually seems to further reduce filesize (at least in the case of fatboy.wav... the bitrate drops from around 270 to 220kbps)... can anyone explain how or why this happens? Is it a bad idea to use it in most situations? I have tried using -q1 in combina! tion with --nspsytune because of earlier discussions saying they could be complimentary, but it seems to either have no effect (most of the time) except being significantly slower, or it actually makes the file sound worse. I am wondering again if -X3 maybe has something to do with that. Any ideas? Dibrom Get your FREE Email and Voicemail at Lycos Communications at http://comm.lycos.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Interesting high quality settings and possible bug
> > pretty much the best I could get but I know for example that > --nspsytune normally enables -X1, but -X3 sounds quite a bit better > although it is significantly slower... which isn't too big of a deal > to me. Also, I know that from earlier conversations --athlower isn't > perhaps the greatest way to control file size (which is what I am > using it for)... however without it the files average 270kbps or more > usually which is a bit too big... using --athlower they come down to > around 230kbps average, although I have had files which reached all > the way up to 290kbps. It also seems that these particular settings > allow a larger bitrate range (ive seen from ~150 to ~290kbps), while > the older settings seemed limited to around ~170 to ~230kbps.. I plan > on posting some information about all of the tests and stuff that I > have done on a website soon.. I would like to hear some opinions on > these settings and my findings. Oh... and about that possible > bug... when using these settings, ocassion! > > At these types of average bitrates, I think you might be better off with CBR instead of VBR. This is because with an average bitrate 230kbs, you only need an extra 90kbs to go up to 320kbs. 90kbs is only 40% of the average frame size - these types of fluctuations are easily handled by the bitreservoir in CBR mode. (it can handle such a fluctuation in 25% of the frames) VBR is more usefull at lower bitrates: take an average bitrate of 128kbs, where you need an extra 250% of the average frame size to make it up to 320kbs. CBR mode can handle such a fluctuation, but for only about 4% of the frames. > aly (about 1 in 10 times or a bit less) while encoding lame will start > giving an error saying: > > ERROR: MAX_HEADER_BUF too small in bitstream.c > The last time I saw this error, it turned out to be because the user was overclocking his system and it was unstable. If that is not the problem, then you need a version of LAME compiled with debugging information turned on. LAME will then probably stop before MAX_HEADER_BUF overflows, with a different, more informative message. Did you compile lame yourself? Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Interesting high quality settings and possible bug
> > Hello... I've been lurking on this list for awhile now and I've > really started to become interested in some of the more advanced > aspects of lame such as the experimental modes and stuff. Basically > what I am trying to get out of lame is the highest possible sound > quality short of using 320kbps cbr. For me size isn't such a big > issue although the smaller the file the better I just figure if > I'm going to be using 320kbps I might as well just go lossless.. > Anyway, over the last week or so I have really started experimenting > with all the different switches and have been measuring their > effects on sound quality via frequency analysis graphs, waveform > subtraction, and most importantly listening tests. When I first > started encoding my mp3s for archival purposes I was using the > switches: -V1 -mj -b128 -q1 (thanks to RoelVdB) and was fairly happy > with the results. After performing the aforementioned tests > however, I have come up with what I consider significantly better > setting! ! > s as far as sound quality is concerned. These new settings are: -V1 > -mj -b128 -q2 -d -p -k -F --nspsytune --athlower -35 -X3. The main > reason I decided to switch to these settings is because they seem to > eliminate pretty much all of the artifacts from the different test > files I used it on, that the older settings were not able to. In > particular, the file where it seemed to make the biggest difference > was in fatboy.wav. With the original settings the file had very > audible and harsh sounding pre echos... The newer settings seem to > almost completely eliminate this problem and the file sounds nearly > identical to the original wav. One thing that I am wondering about > these settings is whether or not they are the optimum way to acheive > what I am trying to do. Basically what I mean is, are some of those > settings conflicting with eachother in some way or another? I don't > really know the internals of lame well enough to figure out for > myself... through my testing they seem to be ! ! > pretty much the best I could get but I know for example that > --nspsytune normally enables -X1, but -X3 sounds quite a bit better > although it is significantly slower... which isn't too big of a deal > to me. Also, I know that from earlier conversations --athlower > isn't perhaps the greatest way to control file size (which is what I > am using it for)... however without it the files average 270kbps or > more usually which is a bit too big... using --athlower they come > down to around 230kbps average, although I have had files which > reached all the way up to 290kbps. It also seems that these > particular settings allow a larger bitrate range (ive seen from ~150 > to ~290kbps), while the older settings seemed limited to around ~170 > to ~230kbps.. I plan on posting some information about all of the > tests and stuff that I have done on a website soon.. I would like to > hear some opinions on these settings and my findings. Oh... and > about that possible bug... when using these settings, ocassion! ! > aly (about 1 in 10 times or a bit less) while encoding lame will > start giving an error saying: > > ERROR: MAX_HEADER_BUF too small in bitstream.c > > It repeats this over and over until it crashes. It only seems to > happen with these particular settings though. Maybe someone can > look into this and see if they find something... it would be nice > not to have it crash. Well thats about it for now... if someone > would like more information just email me. > > Dibrom > > > Get your FREE Email and Voicemail at Lycos Communications at > http://comm.lycos.com > -- > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) > -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
