Re: [MP3 ENCODER] Re: vorbis comment header patch
Thanks. This fix is also in but in a slightly different way. I modifed the actual tagging routines in lame.c to check for Ogg Vorbis output rather than making the client code responsible, so we only have to do the test in one place rather than in all clients. On Fri, Jul 07, 2000 at 01:08:55AM -0700, Ralph Giles wrote: On Thu, 6 Jul 2000, Ralph Giles wrote: Oops, on further investigation those 128 bytes are an id3 tag, so we need an interlock of some sort. I'll take a look at this later. The attached patch should protect against id3 tags in ogg files. I now get a zero-length output file. -- Don Melton mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] --nspsytune
I forgot to mention: There is no advantage to use --nspsytune with CBR 128 as far as I tested. Please use --vbr-old when use --nspsytune. --nspsytune turns on -Z. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] --nspsytune
From: "Naoki Shibata" [EMAIL PROTECTED] --nspsytune command line option turns on following things 1. Addition of simultaneous masking. What does this one mean? 2. MAXNOISE is selected if max/avg exceeds predefined threshold. 3. long block fft window function is changed to blackmann window. 4. new tonality measure is introduced, since it seems that old tonality is not working correctly. 5. Usage of tonality is changed. If tonality exceeds predefined threshold, masking made by that partition is suppressed by 10dB. Ouch, lots more variables to consider. :) -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] --nspsytune
Mathew 1. Addition of simultaneous masking. Mathew Mathew What does this one mean? If there are two or more maskers, produced masking threshold is not just an addition of them, but more than that in most case. I coded this. This page explains same thing, but the formula I used is not same as that on this page. http://ccrma-www.stanford.edu/~bosse/proj/node20.html#SECTION00042600 -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] new VBR code
Fair enough I guess. -Original Message- From: Mark Taylor [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 08, 2000 10:31 AM To: [EMAIL PROTECTED] Subject: Re: [MP3 ENCODER] new VBR code There is so much stuff constantly changing with lamenew options, VBR, CBR, etc.. At this point I have totally lost touch with what mode is what and which flags I should use. I sure hope you guys will start thinking more about usability at some point -steve We do think about usability: That is why the best, and reccommended options (described in the USAGE file), has NEVER changed! It will always be: lame -h input.wav output.mp3 (add -b bitrate for other than 128kbs). Everything else is under constant development and has never been reccommended except for people willing to do (repeatedly) their own testing and evaluation. Whenever something is proven proven to give consistently better results, that feature will be enabled by default with the above options. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] new VBR code
I was under the impression that VBR mode was better...so I have been trying to use it. But at this point I have absolutely no idea if what I'm encoding is better than CBR mode or not. I have absolutely no idea if I'm using a good set of options or not. I'll probably just wait until lame is more finished before I encode any more. Good luck guys. -steve -Original Message- From: Steve Schow [mailto:[EMAIL PROTECTED]] Sent: Sunday, July 09, 2000 10:33 AM To: [EMAIL PROTECTED] Subject: RE: [MP3 ENCODER] new VBR code Fair enough I guess. -Original Message- From: Mark Taylor [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 08, 2000 10:31 AM To: [EMAIL PROTECTED] Subject: Re: [MP3 ENCODER] new VBR code There is so much stuff constantly changing with lamenew options, VBR, CBR, etc.. At this point I have totally lost touch with what mode is what and which flags I should use. I sure hope you guys will start thinking more about usability at some point -steve We do think about usability: That is why the best, and reccommended options (described in the USAGE file), has NEVER changed! It will always be: lame -h input.wav output.mp3 (add -b bitrate for other than 128kbs). Everything else is under constant development and has never been reccommended except for people willing to do (repeatedly) their own testing and evaluation. Whenever something is proven proven to give consistently better results, that feature will be enabled by default with the above options. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] new VBR code
I cannot see the point in using -V0 with "-b %bitrate% -B %bitrate%". I´ve been trying, and can´t see (or hear) the difference. Maybe it´s just me, but I suppose -V0 *must* encode with optimum quality. I don´t know... In this case, if we want minbitrate AND maxbitrate to be 128, why don´t try CBR enconding, sending "lame -h -b128 input.wav output.mp3"? On the other hand, why not use -V1 or -V2, or even -abr? Or maybe I missed something, anyway... Cheers, Aldo (Rio de Janeiro - Brasil) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] --nspsytune
Hi,
I have just commited changes to add --nspsytune option.
With this option, vbrtest.wav is encoded perfectly, and
encoded sound becomes more natural to my ear though encoded file size
increases.
--nspsytune command line option turns on following things
1. Addition of simultaneous masking.
2. MAXNOISE is selected if max/avg exceeds predefined threshold.
3. long block fft window function is changed to blackmann window.
4. new tonality measure is introduced, since it seems that old tonality
is not working correctly.
5. Usage of tonality is changed. If tonality exceeds predefined
threshold, masking made by that partition is suppressed by 10dB.
--
Naoki Shibata e-mail: [EMAIL PROTECTED]
--
Hi Naoki,
I spent some time looking at all these changes. Here are some
comments:
1. This is just a coding issue: This code:
if (gfp-exp_nspsytune) {
for ( k = gfc-s3ind[b][0]; k = gfc-s3ind[b][1]; k++ ) {
gfc-s3_l[b][k] *= 0.7;
}
is probably not in the right place. Right now, the spreading function
is normalized so that (for example) convolving s3 with a constant
function will not remove any energy and return the same constant.
After the spreading function is applied, then you can then adjust the
strength based on the tonality measure, and if you want a uniform
reduction by .7 (1.5db), it can be incorporated later.
(in fact, later it looks like you increase the masking by 2db, so all of
this could be done at that point?)
2. tonality measure:
I cant really understand your tonality measure: it looks like a
comparison between peak and average energy within a partition band?
This is based on the theory that noise is usually has a flat
spectrum, while pure tones would have sharp peaks?
The ISO measure of tonality is based on how stationary a signal is
in time. Thus the ISO formula is based on measuring the change in
energy and phase over 3 granules: if they dont change much over these
3 granules, the signal is considered very tone-like, and if they
change a lot, noise-like.
3. Simultaneous masking: This is based on the theory that
two maskers, when added together, can (but not always?) give
more masking then if the sum of their individual maskings.
I haven't looked at Zwicker's book (Lincoln's reference for this)
but I imagine it is based on tests with just 1 or 2 maskers.
In MPEG, every signal is considered a masker, and they are
being more conservative by just adding them.
4. Your point #5 above is very similar to the ISO formula
which is implemented via "minval" threshold. The strength
of the maskings (computed based on tonality) is not allowed
to exceed a certain threshold. The ISO formula is a little
more complicated in that this threshold depends on frequency:
for low frequencies, minval is more restrictive (resulting
in less masking than would be used w/o minval).
In AAC, minval was dropped. Although it may have been dropped
from the spec but still used in the commercial encoder!
5. MAXNOISE: This is probably the biggest effect?
Switch to a maxnoise formulation and you raise the bitrate
by 20kbps or so, which will improve vbrtest.wav. But
if for example, else3.wav (which sounds fine with VBR)
also has an increase in bitrate for the same quality setting,
that nothing has really changed except the VBR scale.
The real goal is to find something that will increase
the bitrate of vbrtest.wav, without disturbing the bitrate
of other samples which sound ok with VBR.
I've played with MAXNOISE and do not really like it since it is based
on inaccurate energy estimates of single MDCT coefficients, rather
than some kind of averaging. For example, take a signal with a very
large N'th coefficient. A tiny change in this signal can easily move
the energy so that it is now 50%/50% between N and N+1 coefficients.
The thing that doesn't change is the total energy. Thus I think some
type of smoothing needs to be done. A better solution might be to
take the maximum of a moving average of 5 coefficients over all the
coefficients in the band.
6. Blackman window: (I think this is "Blackman", even
though the name is usually spelled Blackmann.)
There is a minor bug in your formula: the window should be centered
over the input data, going to zero at each end, and be periodic with
perioed 1024. Thus window[N]=window[N+1024], and the zero should
occur between sample 1023 and 1024 (sample 1024 = sample 0).
Of course the FFT only takes data sampled at window[0..1023], but those
are the sample values of a function satisfying the above contraints.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] new VBR code
I was under the impression that VBR mode was better...so I have been trying to use it. But at this point I have absolutely no idea if what I'm encoding is better than CBR mode or not. I have absolutely no idea if I'm using a good set of options or not. I'll probably just wait until lame is more finished before I encode any more. Good luck guys. -steve I do all my testing at 128kbs and lower, and I still feel that 128kbs CBR is on average better than VBR (128kbs average) At higher bitrates, (see r3mix.net for example), there is some evidence that VBR outperforms CBR. But this is mostly based on signal processing tests - not hearing tests. hearing tests are hard to perform at such high bitrates because everything sounds pretty good, and I think the evidence is not conclusive either way. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] test
test
RE: [MP3 ENCODER] new VBR code
I am definitely interested in bitrates higher than 128. In my personal opinion, 128 is not good enough. In CBR I would have to encode at 192 to be happy. I was under the impression that if I use VBR mode with 128 as the bottom...that I would get an average about about 185 or so (which is what I have been getting), but the advantage is that in certain sections where it needs to, it uses higher bitrates...and in sections where it does not need to, it would use lower bitrates. Hypotheticall, this would mean overall better sounding music...or more efficient use of bitrates to acheive the best sounding playback. Hypothetically that is.. This is the lame command line I have been using (3.83): lame -V1 -mj -h -p -F -S -b 128 With that, I've been getting average bit rate of around 185. Filesize is about the same as if I had just done 192 CBR, which is satisfactory for me. Question is, is this VBR encoding superior to CBR 192 or not in terms of sound quality? If not, then why bother? I might as well just use 192 CBR and potentially less wierd implications and greater compatability with MP3 players. Secondly, am I using the best command line for what I want out of VBR mode? As you pointed out, its very difficult to tell whether CBR 192 or VBR mode is better in terms of sound quality. What about encoding time? -steve -Original Message- From: Mark Taylor [mailto:[EMAIL PROTECTED]] Sent: Sunday, July 09, 2000 12:24 PM To: [EMAIL PROTECTED] Subject: Re: [MP3 ENCODER] new VBR code I do all my testing at 128kbs and lower, and I still feel that 128kbs CBR is on average better than VBR (128kbs average) At higher bitrates, (see r3mix.net for example), there is some evidence that VBR outperforms CBR. But this is mostly based on signal processing tests - not hearing tests. hearing tests are hard to perform at such high bitrates because everything sounds pretty good, and I think the evidence is not conclusive either way. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Mp3 dB levels
Hi! I'm new here so please don't bash me too hard ;) Anyway, just found this wonderfull encoder, LAME :) I've noticed that it seems to raise the dB level very slighty in the encoded mp3 files, found this out by loading the original .wav file into sound forge and the mp3 one, "clipping" occured in the mp3 file is this normal ? anything u guys (programmers) can fix ?
Re: [MP3 ENCODER] 32 or 44.1kHz for 128 kbit/sec mp3s from soundcard?
When encoding 44.1 kHz audio to a 128kbit/sec mp3, lame by default cuts off the high end with a transition band of 15115 Hz - 15648 Hz. (32 kHz audio to 128kbit/sec mp3 has a slightly lower cut-off by default with a transition band of 14065 Hz - 14452 Hz.) If someone was encoding 128kbit/sec mp3s from their soundcard (ie from an analog source like a mixer instead of a CD rip) and was okay with these default low pass filter frequencies, should they probably use 32kHz as the sample rate instead of 44.1 kHz? Seems to me about the same frequencies would be represented ( ~20 Hz up to around 15 or 16 kHz) but the compression ratio wouldn't be as big for 32kHz. Would that lower compression ratio result in better sound quality? Or does more samples a second result in better sound quality at all frequencies? If you test this out, let us know the results. FhG's encoder will automatically downsample to 32khz if you encode stereo 96kbs, but at higher bitrates they leave the samplerate at 44.1khz. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] -h (High quality causing ringing artifacts ?) ?
Quality (default value Normal): With the LAME encoder, you can specify the output quality; thus you can trade off encoding time against sound quality. The default (normal) is recommended, since the high output option might cause ringing artifacts at lower bit-rates. The voice quality is more or less optimized to generate the best quality for voice only WAV files (e.g. books on CDs). Taken straight from the cdex 1.30 beta1 help page, is this true with 3.85 ? does it really cause ringing artifacts with high quality on ?
Re: [MP3 ENCODER] Re: vorbis comment header patch
On Sun, 9 Jul 2000, Don Melton wrote: Thanks. This fix is also in but in a slightly different way. I modifed the actual tagging routines in lame.c to check for Ogg Vorbis output rather than making the client code responsible, so we only have to do the test in one place rather than in all clients. Huh. I thought it made more sense to make the client code responsible as long as the routines had 'id3' in the name. If you are reworking things, please be aware that the vorbis comment header is more flexible, basically allowing arbitrary token-stringvalue pairs (though there is a standard set that players/encoders should recognize) and there can be multiple instances of the same tag. So it would be nice to be able to say: lame --ogg --ta "Peter Gabriel" --ta "Kate Bush" \ --tag "CDDBID=foo" song.wav song.ogg and have it handle things properly. But obviously this complicates things quite a bit. Thanks for the commit, -ralph -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] -h (High quality causing ringing artifacts ?) ?
David, Avoid HTML mail. Please send text-only e-mails to this list, since this list is intended for multiple people who uses mail agents other than Outlook Express 5.0, and even non-Microsoft platforms. Claudio -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] lame exit problems
Is there any way to force a DOS box close after lame has completed encoding? With the Windows binary, it exits properly but with the DOS one it just says Finished and the box stays open. So if I'm using the DOS version to encode with say audiograbber, I can never get to the next track without manually closing the box. Josh -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame exit problems
Click on Props for the DOS icon, select Program and place a tick in "Close on Exit" - Original Message - From: "Joshua Bahnsen" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 10, 2000 12:56 PM Subject: [MP3 ENCODER] lame exit problems Is there any way to force a DOS box close after lame has completed encoding? With the Windows binary, it exits properly but with the DOS one it just says Finished and the box stays open. So if I'm using the DOS version to encode with say audiograbber, I can never get to the next track without manually closing the box. Josh -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] lame exit problems
Title: RE: [MP3 ENCODER] lame exit problems This should work. Right-click the icon at the top left of the DOS window. Select Properties in the Program tab select Close on Exit. This will create a LAME.PIF which Windows should recognise when loading LAME.EXE. Ross. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Joshua Bahnsen Sent: Monday, 10 July 2000 14:56 To: [EMAIL PROTECTED] Subject: [MP3 ENCODER] lame exit problems Is there any way to force a DOS box close after lame has completed encoding? With the Windows binary, it exits properly but with the DOS one it just says Finished and the box stays open. So if I'm using the DOS version to encode with say audiograbber, I can never get to the next track without manually closing the box. Josh -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] {qadjust=-2.5} to {qadjust=-.5 and -q1} ? (lame)
After 8-9 hours of trying to grasp a fraction of the source (no programmer, no psy-coding background, plain dumb :)) (in a futile attempt to find the reason why "-b" is misinterpreted (?)) this catched my eye: qadjust=-2.5; /* start with -1 db quality improvement over quantize.c VBR */ in Mark's vbrquantize.c. Why this "-2.5"? Anyways, I changed the thing to some other values and "qadjust=-.5;" combined with "-q1" gives filesizes/bitrate distributions very much like the --old-vbr. (meaning: V1,JS=transparent for most, at 170-180kbit/s average) You are right - that is a tunable parameter that just adjusts the -V scale. There is no particular quality associated with -V1 (or any other setting) - it is just a sliding scale that can be adjusted to anything you want. With VBR (both modes), each frame is encoded with as few bits as possible so that: quantization_noise allowed_masking - N db and the -V setting (and that quality adjustment) just change the value of N. (allowed_maskings are the maskings computed by psymodel.c) The goal is something like this: VBR_q compression like 4.4 320kbs/41khz 05.0 5.5 256kbs/41khz 16.0 27.0 7.3 192kbs/41khz 38.0 8.8 160kbs/41khz 49.0 611 128kbs/41khz 914.0 14.7 96kbs So -V6 is supposed to give, on average, 128kbs. -V0 is supposed to give, on average, 256kbs. This doesn't really make sense because you might as well just use 256kbs CBR, but this is because many people expect that -V0 should give the best possible quality. -V1 should be around 220kbs, and with another 20% reduction from jstereo, that is down to 180kbs. All the various default settings (jstereo, lowpass filtering) are based on the compression ratio. For VBR, the compression ratio is not known in advance, so LAME uses the above table. Negative: - some nasty artifacts in a file I encoded (every vbr_mt does worse than vbr_rh on this file), I'll address this in another thread. (*, if desired) yes, please send me the .wav files with a description of the problem. I have two samples already with artificts, but I haven't had a chance to figure out what is wrong. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] --nspsytune
Hi, I have just commited changes to add --nspsytune option. With this option, vbrtest.wav is encoded perfectly, and encoded sound becomes more natural to my ear though encoded file size increases. --nspsytune command line option turns on following things 1. Addition of simultaneous masking. 2. MAXNOISE is selected if max/avg exceeds predefined threshold. 3. long block fft window function is changed to blackmann window. 4. new tonality measure is introduced, since it seems that old tonality is not working correctly. 5. Usage of tonality is changed. If tonality exceeds predefined threshold, masking made by that partition is suppressed by 10dB. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] id3 tag support
On Sat, Jul 08, 2000 at 09:39:59PM -0400, Joshua Bahnsen wrote: Has there ever been any thought of using something like id3lib http://id3lib.sourceforge.net to handle tagging? Yes. When I rewrote the tagging code recently to add ID3 version 2 support I considered it. But if you look at my original proposal on the mailing list at: http://www.mail-archive.com/mp3encoder@geek.rcc.se/msg03336.html ... you'll see that I wrote ... "I plan to use (other) code instead of id3lib (see http://id3lib.sourceforge.net) because the 'official' library is a rather large collection of C++ and not available on anything but *nix and Win32 currently, and it's not typically pre-installed on those platforms as a .so or .dll. Also, the code needed to write the tags is actually very simple. Reading, parsing, and editing ID3 version 2 tags (which LAME doesn't need) is the hard part and most of the reason for the large size of id3lib." Eventually, I hope that id3lib DOES replace the built-in LAME tagging code simply because that will reduce the complexity and maintenace costs of LAME. But because of the availability problem (one of the same reasons Ogg Vorbis support isn't enabled by default) that won't happen for awhile and I wanted ID3 version 2 tagging support on by default. Also, the folks at id3.org are in the process of updating the ID3 version 2 specification to revision 4, and that will complicate id3lib development since it tries to track the spec closely. -- Don Melton mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
