As low anchor it's OK, but not as contender. Decide between Blade and Shine. I would go with Shine.
Hi. I'm still running into new material encoded at Blade 128 so anything that might help to stop its use would be useful. It should make a good low anchor. Shine would too but this is used rarely it seems.
L3ENC 0.99a still works but it leaves a pop sound on the begaining of the MP3, I have not tried the other versions through.
I tried the oldest version of l3enc a while ago to see the improvements of the MP3 formats over the last 10 years.L3ENC 0.99a still works but it leaves a pop sound on the begaining of the MP3, I have not tried the other versions through.
l3enc v. 1.00 has the same problem. This click makes mp3 files that are encoded from wave source files unsuitable for testing purposes. It makes the measured track volume levels incorrect even if the beginning of the file is excluded in the used ABC/HR configuration. However, raw pcm works fine.
1.1 PCM audio input file The first command line argument specifies the name for the PCM audio data file. Version 1.00 of the encoder accepts either raw PCM audio data files or PCM audio data files in RIFF/WAVE format as used by Microsoft Windows. The samples must be 16 bit signed integer values. The sampling rate must be 44.1 kHz. A) raw PCM audio data By default the input file is assumed to contain raw PCM audio data. Stereo audio data is input in interleaved format, the first channel beeing the left channel. <sample #1 channel #1> <s. #1 ch. #2> <s.#2 ch.#1> <s.#2 ch.#2> ... Mono audio data has the format <sample #1> <sample #2> <sample #3> .... Whether the input file is treated as mono or stereo audio data is set by the encoding mode parameter (1.3). Default is stereo. B) RIFF/WAVE format If the '-wav' option is specified, the input file is assumed to contain 16 bit PCM audio data in RIFF/WAVE format as used by Microsoft Windows. Audio parameters are extracted from the Wave header and checked against the settings of the encoder. If not supported options are found (e.g. 8 bits/sample), the encoding process is aborted. The encoding mode (mono or stereo) is determined by the settings in the WAVE header.
If we force LAME to use ABR/CBR then we should logically force all other competitors to use the same kind of setting (otherwise the test will look as a very dubious one)....I would try to avoid VBR/CBR confrontation (and as I said, I don't consider a CBR-only test as a useful solution).
iTunes is said to perform better at CBR than VBR. Forcing iTunes to use VBR was one of Roberto's mistakes in his test.
But if you're going to run a 128-ish VBR test, don't call it 128 kbps.