I encoded Lush's album "Split" with --alt-preset standard. The average bitrate for the album was 235 kbps (as reported by mad) which is high, but not unusual.
But the fifth track on that album "Lovelife" checked in at 273 kbps! There is nothing sonically unusual in that song as far as I can hear. I have had tracks with high --alt-preset standard bitrates before, but they are always understandable, like noisy Flying Saucer Attack tracks.
Any ideas on what could be causing the bitrate inflation? It's not a problem, I'm just curious.
--jth
I have a Throbbing Gristle album (Greatest Hits) which has the same issues on a couple songs. There's not a lot going on in the song and a couple of the songs still reach as high as 280kbps w/ aps.
-Jeffrey
The only things which could cause --aps to use such a high bitrate are either excessive transients (short attack like sounds.. maybe pops or ticks or something like that), or impulse sounds.
Whatever the tracks are doing, they must be triggering a whole lot of short blocks.
Thanks for the reply. This song doesn't fit any high-bitrate stereotypes like metal or industrial music. It's best described as "jangly" pop music. I'll have to take a look at the file with encspot to see if there is anything out of the ordinary.
--jth
I'm wondering how high would be the bitrate with -Y switch, for those album.
I've found it cutting bitrate very much, especially in songs with very high bitrate (though I've tested especially metal music.)
Originally posted by jkeating
I'm wondering how high would be the bitrate with -Y switch, for those album.
I've found it cutting bitrate very much, especially in songs with very high bitrate (though I've tested especially metal music.)
If the bitrate increases are caused by large amounts of short blocks (only way the bitrate should really be that high with --aps), then -Y shouldn't really have a large effect. That only really makes a difference on music like metal with a lot of loud high frequency content. It could be possible that it's a combination of both in these cases.. but it doesn't sound likely from the way it was described.
Might be worth a shot anyway though.
I checked the original 273 kbps encode with encspot:
stereo:
ss 28.5%
ms 71.5%
blocks:
long 99.1%
short 0.9%
So I re-encoded with -Y as suggested and the bitrate is much reduced to 175 kpbs.
However, it sure sounds different to me than without -Y. I wish I had time to run a proper ABX on it.
--jth
Very interesting.....
Can you upload a short clip of this somewhere maybe?
And what kind of music is this? It's not metal or anything.. is it something very noisy and compressed? Or maybe it's fairly quiet with a lot of background noise.. that might create a similar situation... but I've never quite seen it to that extreme.
No, it doesn't really fit those descriptions at all. Just a regular electric guitar and percussion intro with some echo and flanging effects which are apparent when the vocals kick in at 20s. I think this kind of music is called "shoegazing" or "dreampop."
The bitrate is quite high from the very beginning. I think the first 30s of the track are indicative enough of the track as a whole.
I do have a website where I can upload a wav. I'll post it in a little while.
--jth
I don't know what the preferred lossless format is, but I posted a flac and wav file (3.5 and 4.5 MB respectively)
lovelife.flac (http://68.98.50.32/music/lovelife.flac)
lovelife.wav (http://68.98.50.32/music/lovelife.wav)
--jth
Did anyone get a chance to look at/listen to this interesting sample?
thanks
--jth
I have the album although I have not encoded it. However, I also have the track "Ladykillers" on Now That's What I Call Music! 33 which I have encoded with aps, where I get 213 average (as shown by winamp). If someone wants me to encode my copy of the album, just say
@jth
Your link is broken. Can you fix it?
I also have some Dark Funeral that gives ~2 % of short blocks & a bitrate of ~280 on a track, but that is some really fast & heavy metal, so i guess it makes some kind of sense ...
fix the link
Bah,
My ISP has blocked web server port 80, I wonder if Code Red 2 has appeared.
Anyway, I moved the web server to port 81, try these URLS:
lovelife.flac (http://68.98.50.32:81/music/lovelife.flac)
lovelife.wav (http://68.98.50.32:81/music/lovelife.wav)
--jth
@jth,
What CD/song are those clips from? My copy of "Lovelife" doesn't have a song that opens like that. I haven't listened to the whole disc in a while, so if that's from mid song, I'm confuzzled.
Anywho... I encoded your clip on my box and got 244 kb/s -- is this what you're seeing? Using --aps -Y yields 186 kb/s.
Track 5, "Papasan" from my copy of "Lovelife" clocks in at 148 kb/s with aps.
This is the intro to track 5 "Lovelife" on the "Split" album, the one before the "Lovelife" album, confusingly enough.
It's like how "Houses of the Holy" was on "Physical Graffiti" but backwards.
My encode gives 268.1 kbps (the whole song encodes slightly larger at 273 kbps). This is with the latest CVS compile. Which compile are you using?
--jth
Ah yes, it got me confused! Sorry...
Originally posted by jth
This is the intro to track 5 "Lovelife" on the "Split" album, the one before the "Lovelife" album, confusingly enough.
Ah, no wonder I was so confused. Sorry 'bout that.
My encode gives 268.1 kbps (the whole song encodes slightly larger at 273 kbps). This is with the latest CVS compile. Which compile are you using?
I'm using Motiok's 3.92 compile. When I get home from work I'll yank down some other compiles and check out the results.
I hope the issue isn't with the compile. I encode on Solaris/UltraSparc. I have a rather large library encoded with these settings. I do remember comparing the Solaris compile with Intel binaries when --aps was introduced and getting identical results. I'll have to take a look to see if that's still the case. I suppose you can assume it's a bug in lame or your compiler when the same switches give different results on two different architectures.
--jth
I haven't really had a chance to look at this sample yet, but if you guys are getting high bitrates with the latest CVS, then I wouldn't be too surprised. Things are not really stable at all in the latest alphas, and they shouldn't be used. I've not made any attempt whatsoever to even verify that the alt-presets work correctly in anything beyond 3.92.
The 244kbps that Ardax quoted is much more what I would expect from a top end bitrate in this kind of music. If it's going beyond that, it's likely to be either due to short blocks (we already established that it wasn't), or changes in the code (in the latest CVS for example...).
Anyway.. in general, alpha's shouldn't really be used for regular encoding or for quality comparison. Certainly not the recent ones at least... there have been some pretty big quality issues in some of the more recent alphas.
Btw, I can verify that 3.92 gives 244.7kbps on my box.
That's sensible advice. I do have a small list of samples that I verify produce the same encodes as 3.92 before moving on to the latest CVS. I'm using version 3.93a2. I recently helped the lame maintainers add some GCC ultrasparc optimization flags to the lame compile, but I don't think that is causing any problems.
I tried this sample with my 3.92 and I get the same result as Ardax!
Good news - I have a new test sample to add to my collection. Bad news - I might have a couple of albums with inflated bitrates or quality problems.
Do you think the lame developers would be interested in this sample or is it already a known issue?
thanks
--jth
Originally posted by jth
Do you think the lame developers would be interested in this sample or is it already a known issue?
Hrmm. Well, it wouldn't hurt to tell the rest of the guys. I don't think it's really so much of an issue with the sample though as just some recent changes made to the code. Might as well mention it to them though. However, as far as the alt-presets go, I'm the only one who maintains those... so if it's a problem which is mostly only evident there, then I doubt the other guys will do much with it Right now I'm pretty much taking the stance that I'll see about "fixing" anything that may have been broken only when 3.93 goes stable. There's not much of a need to use the latest CVS versions over 3.92 right now (though some of the speed improvements would be kind of nice I guess... ) so I don't really find it pressing to try and keep the presets stable within an inherently unstable developmental version.
C:Downloadlove>lame --alt-preset standard lovelife.wav
LAME version 3.91 MMX (http://www.mp3dev.org/ (http://www.mp3dev.org/))
(Win32 binaries from http://mitiok.cjb.net/ (http://mitiok.cjb.net/))
CPU features: i387, MMX (ASM used), 3DNow!
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding lovelife.wav to lovelife.wav.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.4x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
984/986 (100%)| 0:10/ 0:10| 0:10/ 0:10| 2.6935x| 0:00
128 [ 18] %***
160 [ 22] %%***
192 [150] %%%%%%%%%%%%%%%%****************
224 [236] %%%%%%%%%%%%%%%%%%%%******************************
256 [316] %%%%%%%%%%%%%%%%%%%%%%%%%%%***************************************
320 [244] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*******************
average: 250.0 kbps LR: 454 (46.04%) MS: 532 (53.96%)
Writing LAME Tag...done
C:Downloadlove>dir
19/06/2002 19:00 4,536,084 lovelife.wav
26/06/2002 17:04 804,419 lovelife.wav.mp3
Thanks Dibrom, I'll make a post to the dev mailing list - there's no harm in passing it along.
--jth