Hello.
I'd like to start discussing a listening test at 48kbps.
The official reason for that bitrate is to test formats working on dial-up streaming bitrates. But my particular reason is that I would like if everyone is able to participate in my last test.
The test is scheduled to start on June 30th.
The formats I'm considering are:
- Ahead HE AAC+PS (if it's released until then. If not, I'll use HE AAC only)
- Vorbis aoTuV
- MP3pro
- WMA
- Real Audio
- QDesign
- High anchor?
I don't see much point featuring a bottom anchor, considering the bitrate is already very low.
The samples will probably be pretty much the same as the 128kbps test. I'm open to suggestions to replace samples, though.
To avoid missing the test once it starts, I suggest that interested people subscribe to the listening test newsletter (http://www.rjamorim.com/test/newsletter.html).
Thank-you for your comments and feedback.
Best regards;
Roberto.
48 kbps doesn't work with dial-up eventhough it should be theoretically possible. If you want to test dial-up bitrate you should use 32 kbps.
BLADE or l3enc 128 mp3 as high anchor!
48 kbps doesn't work with dial-up eventhough it should be theoretically possible. If you want to test dial-up bitrate you should use 32 kbps.
Hrm... I remember listening to 48kbps Real Audio when I was on 56kbps dial-up. It was being broadcasted from my ISP, though.
BLADE or l3enc 128 mp3 as high anchor!
Do people still use them, even?
48 kbps doesn't work with dial-up eventhough it should be theoretically possible. If you want to test dial-up bitrate you should use 32 kbps.
Hrm... I remember listening to 48kbps Real Audio when I was on 56kbps dial-up. It was being broadcasted from my ISP, though.
I never get over 32 kbps.
I'm on dial-up and I regularly can stream ~42kbps videos. Yes, it's not that normal bitrate, but that's what Realplayer reports.
Roberto,
Please please make it ~32kbps... I've just had no luck going above that on a UK connection - I've never seen anything stream higher than that on a dial up successfully...
Ruairi
Please please make it ~32kbps... I've just had no luck going above that on a UK connection - I've never seen anything stream higher than that on a dial up successfully...
Jeez. But then the samples will sound so bad...
Well, if people prefer 32kbps, I'll oblige. Please post your opinion on this matter.
Please use 32k. That's the higest rate I've been able to get reliable and consistent streaming to work with dial-up. Dial-up speeds can reach or exceed 48kbps, but maintaining it for any length of time is very unlikely.
Jeez. But then the samples will sound so bad...
lol! It's a far cry from near-transparent, eh?
If you're going to use 32 kbps, how about using the 7 kHz and 3.5 kHz lowpass anchors that MUSHRA uses? They also use a different rating scale (which I believe abchr-java can accomodate). That way, you could get results which might be comparable to what they got when they tested 32 kbps codecs.
80-100 excellent
60-80 good
40-60 fair
20-40 poor
0-20 bad
ff123
Another vote for 32k. Even though I no longer use Dial up (thanks god!) I would bet it's still crap = no more than 32k
At 48 kbps ATRAC3plus could be considered, too. But it will probably never be chosen for dial-up broadcasting.
At 32 kbps, mono broadcasting ist very popular, at least with mp3 and ogg vorbis. Therefore, MP3 @ 32 kbps mono may be interesting.
If you're going to use 32 kbps, how about using the 7 kHz and 3.5 kHz lowpass anchors that MUSHRA uses? They also use a different rating scale (which I believe abchr-java can accomodate). That way, you could get results which might be comparable to what they got when they tested 32 kbps codecs.
80-100 excellent
60-80 good
40-60 fair
20-40 poor
0-20 bad
ff123
Interesting.
That's indeed a good idea. I think ABC/HR java can only customize the ranking labels (Imperceptible, Annoying, etc.), you can't change the scale values (it always goes from 1 to 5).
So, the codec list can now be:
- Ahead HE AAC+PS (if it's released until then. If not, I'll use HE AAC only)
- Vorbis aoTuV
- MP3pro
- WMA
- Real Audio
- QDesign
- 7kHz lowpass for high anchor
- 3.5kHz lowpass for bottom anchor
(BTW, if you guys are wondering what test ff123 is talking about, it's here (http://www.ebu.ch/trev_283-kozamernik.pdf))
Maybe I have a "tin ear", but I'm listening to a 32k bitrate, 22KHz stereo MP3 stream, and find it quite acceptable - not sure which encoder it's using though - and it's "old time" radio, so it may start out lacking the high frequencies that tax low bitrate MP3.
On to bitrate (for Dialup)
44-49k are typical, I count 45k as "average" and 48-49 as "excellent".
38k has been observed on poor modems, or under bad conditions.
If it falls back, it's as likely to hit 31.2k as 33.6 - so even 32k is pushing the limit for "guaranteed dialup streamable".
28k modems have been observed to fall back to 26k under not uncommon conditions.
The really tough target, for guaranteed dialup streamable, would have to be 24k, though 32k is a fair choice if you hope for a 56k connect, and get a GOOD V34 - for a 56k connect, 40k would be more achievable than 48k.
I'd like to see bog-standard MP3 put through it's paces, as if you're listening to low bitrate internet radio now, it's probably going to be MP3 - so how bad IS it, do the alternatives justify the cost or effort in obtaining and installing, and tolerating the bad habits of REAL and MS.
If MP3 at low bitrate is as bad as we expect it to be, it should take the "bottom anchor" position, and be ABX'ed 100% - but at low bitrates, we can expect ALL codecs to do considerable damage.
Hmm, Qdesign is included in Quicktime, but is it used by any Internet broadcaster?
Just one idea:
Include a speech sample in the test. At least I presume that the purpose of this test is to test Internet radio compression.
Hmm, Qdesign is included in Quicktime, but is it used by any Internet broadcaster?
Several of the trailers at quicktime.com are/were encoded with QDesign.
Just one idea:
Include a speech sample in the test. At least I presume that the purpose of this test is to test Internet radio compression.
Yes, I will probably replace one of the problem samples with a speech sample.
Suggestions of sample?
I got H.G. Wells; War of the Worlds audiobook by Jeff Wayne, and "Star Wars - The original radio drama" if you're interested... Need to rip the CDs first tho
Yes, I will probably replace one of the problem samples with a speech sample.
Suggestions of sample?
I don't really have suggestions for a sample, but do you think that only one speech sample is representative of streaming at this bitrate? The MUSHRA comparison had 4 speech samples out of 9 total.
ff123
I think this is one of the tests almost everyone can get involved with - 56k rates are so much easier to determine the quality of.
Ruairi
I got H.G. Wells; War of the Worlds audiobook by Jeff Wayne, and "Star Wars - The original radio drama" if you're interested... Need to rip the CDs first tho
Yes, I'm interested. Thank-you very much.
I don't really have suggestions for a sample, but do you think that only one speech sample is representative of streaming at this bitrate? The MUSHRA comparison had 4 speech samples out of 9 total.
Interesting.
Well, I'm open for suggestions. We can ditch some of the musical styles and reduce the amount of classical samples to fit more speech samples.
I believe it would indeed be interesting to have one male monologue, a female monologue, a dialog...
I don't plan to feature more than 18 samples.
Is speex not useful at this bitrate,or simply not tuned for music?
I can provide a cappella sample(Suzanne Vega - Tom's Diner) which might be used in place of speech sample.
Uploaded here (http://www.hydrogenaudio.org/forums/index.php?showtopic=20498&view=findpost&p=219128).
BTW, I'd like to see ATRAC3plus 48kbps in the test.
Is speex not useful at this bitrate,or simply not tuned for music?
Dunno the case with speex, but most voice coders fail VERY badly on music and complex sound effects.
I think Speex belongs to a test dedicated to vocodecs. I already started discussing such test with jmvalin, hopefully he'll have time to conduce it (or someone else might become interested).
I can provide a cappella sample(Suzanne Vega - Tom's Diner) which might be used in place of speech sample.
http://pessoal.onda.com.br/rjamorim/hh.jpg (http://pessoal.onda.com.br/rjamorim/hh.jpg)
32kbps sounds very decent for mono old time radio shows; I have several GBs of such shows in MP3 format. After my recent experiments for my own website OTR stuff I think that AAC (using the Compaact! encoder, no idea how Nero does in that range) sounds far better using the VBR encoder on the quality 1 or 2 setting.
Encoding a 1953 episode of the syndicated series 'The Third Man' (AKA The Lives of Harry Lime and Harry Lime Adventures) using those settings with a length of 20:23 gave me a file 8.45 MB in size. edit: forgot to mention that the average bitrate is 50-60kbps but easily hits 40 or less on a slightly lower setting. Original source was a tape.
That was the smallest I could go with my high personal standards after listening to enough 30 minute circa 6.5 meg MP3 files that sound decent but could be better.
I believe it would indeed be interesting to have one male monologue, a female monologue
For this we can test the EBU SQAM disc tracks, there are female and male speech samples: http://www.tnt.uni-hannover.de/project/mpeg/audio/sqam/ (http://www.tnt.uni-hannover.de/project/mpeg/audio/sqam/)
A 32kbps audio stream is usually the most you can extract from a 56k modem, sometimes higher but what usually happens then is jittery playback with regular rebuffering.
AFAIK, even though the modem has a higher bandwidth than 32kbps and the protocol is usually UDP there is still some overhead bandwidth which knocks several kbps onto the stream. (Correct me if I'm wrong)
Hello all,
I agree that 32 Kbps is an interesting data point, both for modem audio streaming, and for the audio track of a video stream at moderate broadband data rates.
A few points:
Might be interesting to hear LAME using its low bitrate tuned modes. No 32 Kbps preset
QDesign testing will need to be done with the full QDesign Music Pro 2 version, not the free one with QuickTime. However, that codec is largely deprecated for QuickTime use these days in favor of Apple's MPEG-4 AAC-LC codec.
For RealAudio, we should probably test both RealAudio 8 Stereo Music (aka "cook") and the new RealAudio 10 codec (AAC-LC based). Note the RA8 stereo codec is way better than the RA mono codec, even with mono source.
The "sweet spot" KHz for optimal quality might vary from codec to codec. I'll argue it's better to pick the right sample rate for each codec in order to let each codec show its best.
And if this goes well, maybe we should do another test at 16 Kbps. There's a lot of interest there for audio for modem rate video streams, and for mobile devices and streaming radio. The WMA Voice codec does nicely there.
I've deployed audio content down to 4 Kbps for real-world projects.
For RealAudio, we should probably test both RealAudio 8 Stereo Music (aka "cook") and the new RealAudio 10 codec (AAC-LC based).
The Real AAC codec doesn´t go below 64kbps, so the only codec that can be used at this bitrate (32 or 48 kbps) is cook (ok, there was dnet (DolbyNET, AC3 with low samplerate extension) once, but that codec isn´t featured anymore for years).
But still there are four flavors that could be used:
Flavor | Codec Bitrate Label | Freq Resp | Sample Rate
| | |
20 | 32 Kbps Stereo Music RA8 | 10.3 kHz | 22050 Hz
21 | 32 Kbps Stereo Music RA8 High Resp. | 13.8 kHz | 44100 Hz
22 | 48 Kbps Stereo Music RA8 | 13.8 kHz | 44100 Hz
23 | 48 Kbps Stereo Music RA8 High Resp. | 16 kHz | 44100 Hz
AFAIK, even though the modem has a higher bandwidth than 32kbps and the protocol is usually UDP there is still some overhead bandwidth which knocks several kbps onto the stream. (Correct me if I'm wrong)
Shoutcast/Icecast use TCP. But yes, there is still overhead either way--TCP adds a bit more.
,Jun 19 2004, 06:46 AM] For this we can test the EBU SQAM disc tracks, there are female and male speech samples: http://www.tnt.uni-hannover.de/project/mpeg/audio/sqam/ (http://www.tnt.uni-hannover.de/project/mpeg/audio/sqam/)
Great idea! Thanks.
Might be interesting to hear LAME using its low bitrate tuned modes. No 32 Kbps preset
Well, I guess it could be used as lower anchor...?
QDesign testing will need to be done with the full QDesign Music Pro 2 version, not the free one with QuickTime.
I have (http://www.rjamorim.com/rrw/qdmc.html) the demo of QDMC Pro 2, that lasts for 15 days. I'll use it for my test.
The "sweet spot" KHz for optimal quality might vary from codec to codec. I'll argue it's better to pick the right sample rate for each codec in order to let each codec show its best.
I agree. Some codecs already resample automatically when low bitrates are used. Other codecs might need a hand.
Hey, Ben !!!
"Note the RA8 stereo codec is way better than the RA mono codec, even with mono source."
?????
I'm from Missouri......
But still there are four flavors that could be used:
Flavor | Codec Bitrate Label | Freq Resp | Sample Rate
| | |
20 | 32 Kbps Stereo Music RA8 | 10.3 kHz | 22050 Hz
21 | 32 Kbps Stereo Music RA8 High Resp. | 13.8 kHz | 44100 Hz
22 | 48 Kbps Stereo Music RA8 | 13.8 kHz | 44100 Hz
23 | 48 Kbps Stereo Music RA8 High Resp. | 16 kHz | 44100 Hz
Maybe we should ask Karl Lillevold if he could tell us which version to use.
And if this goes well, maybe we should do another test at 16 Kbps. There's a lot of interest there for audio for modem rate video streams, and for mobile devices and streaming radio. The WMA Voice codec does nicely there.
That's exactly what I thought too. I hope this test will be done at 32 Kbps, 44 Khz stereo and it will be great if we could have another test at 16 Kbps.
I hope this test will be done at 32 Kbps, 44 Khz stereo
I do not see the point in forcing codecs to use 44.1kHz.
Are any VBR/ABR settings going to be used at this low bitrate?
If so the samples should give bitrates below 32kbps/48kbps and above 32kbps/48kbps. Ideally in the shape of a bell curve!
This way the test would not be biased towards VBR encoders. As you are testing the samples that it may have underestimated the bitrate needed.
If only CBR setting will be used then ignore this post.
I do not see the point in forcing codecs to use 44.1kHz.
Right. I don't think anyone on his right mind would encode audio to 32kbps at 44.100Hz. I am considering either resampling everything to 22050 (I guess that's what people encoding to this bitrate would do), or letting the encoders choose the appropriate sampling rate.
Are any VBR/ABR settings going to be used at this low bitrate?
Vorbis and AAC will use VBR, unless I'm advised todo otherwise. QDesign and Real, of course, won't. I'm not sure about WMA. It seems to me it doesn't offer two-pass VBR for sampling rates other than 44.1 and 48kHz...?
If so the samples should give bitrates below 32kbps/48kbps and above 32kbps/48kbps. Ideally in the shape of a bell curve!
I agree. I'll soon start juggling samples around trying to find a nice bitrate deviation curve.
I did a bitrate test of sorts for aoTuVb2:
First I took 18 tracks, one from each of the 18 albums I encoded for the 128 kbps multi-format test. Each of these tracks averaged about the same as the entire album did. Then I threw out highest, lowest, and cut from the top until I had 13 tracks which averaged 128 kbps using -q 4.35. The actual bitrates were:
122, 123, 124, 124, 125, 127, 128, 129 , 131, 131, 132, 133, 135
This averages 128; also the median is 128, so it's pretty well centered.
Next I used these 13 tracks to encode using aoTuVb2 --resample 32000 -q -2
Bitrates were:
27, 35, 38, 36, 33, 40, 40, 41, 36, 43, 36, 46, 46 (in the same order as above)
This averages to 38; also the median is 38.
This is too high for a 32 kbps test. At least if we assume an all music test. I don't know what speech samples would do to the average.
ff123
BTW, 38 kbps average aoTuVb2 is actually listenable (at least for me)!
Edit: speech samples don't help bring down the average bitrate:
female english: 40
male english: 42
female french: 40
male french: 43
female german: 39
male german: 41
Okay, this started out as a 48kbps test and everybody complained that you can't actually stream 48kbps on most dial-up connections. So that is obviously the most important part of this test. (streamability on a dialup connection) So why use VBR for any of the samples then? VBR + streaming is not a good idea, especially if the person's buffer is not very large (usually not, people don't like to wait.) VBR on low bandwidth connections is an awful idea because when it peaks to 64 or 96kbps you may experience dropouts. Just my 2c.
Okay, this started out as a 48kbps test and everybody complained that you can't actually stream 48kbps on most dial-up connections. So that is obviously the most important part of this test. (streamability on a dialup connection) So why use VBR for any of the samples then? VBR + streaming is not a good idea, especially if the person's buffer is not very large (usually not, people don't like to wait.) VBR on low bandwidth connections is an awful idea because when it peaks to 64 or 96kbps you may experience dropouts. Just my 2c.
Just exploring the bitrates and the test assumptions. Assume that there was a vorbis vbr setting that averaged 32 kbps. Would the deviation about that bitrate be small enough to allow it to be considered in a dialup test? If you subtract 6 kbps from each of the bitrates I found, you'd get 40 kbps for the highest track. Seems like it's at least arguable that it could work.
In any case, another setting needs to be found. Bitrate managed may be the only option.
ff123
Ok, here's aoTuVb2 --resample 22050 -b 32
where -b is bitrate managed mode (but still VBR). The tracks now are:
29, 31, 34, 34, 33, 34, 36, 36, 33, 37, 34, 35, 34, for an average of 34 kbps.
This is better, but now we're in the debatable range of whether or not a track which averages 37 kbps is acceptable or not. BTW, I could not use -b 32 if I resampled at 32 kHz.
ff123
Edit: these sound a lot worse than the -q -2 files
Edit2: using -b30 reduces bitrates another 2 kbps, to what is most likely acceptable on even the high tracks.
Are Ayumi's changes even operating in this mode? Why is 22 kHz resampling forced at this bitrate? Maybe 32 kHz would sound better.
Not sure I'm upto date on all streaming codecs, but some things to consider:
1) Why not hard limit upper range of bit rate?
I think that would be a relatively fair assumption for streaming conditions. Using VBR and then calculating arbitrary averages isn't necessarily going to work under real streaming conditions. If average path is chosen, then it'll be more like a "pseudo streaming" codec test, no?
So, would CBR or hard-limited max bit rate be a better choice, considering this is a streaming test and that the results should reflect that (and not pseudo-idealized conditions)?
2) I also vouch for using at least two langauges (in speech samples) if possible.
This is not about trying to represent all the world languages, but trying to find for example languages that have widely differing fricative frequency/type and intonation. These can throw different problems for different codecs. I'd suggest Engl/Ger as minimum two myself. Spanish is much lower in frequency on certain type of hard fricatives as is French.
Excellent test idea, btw! Thanks again to rjamorim for being brave by facing the task (again!).
Not sure I'm upto date on all streaming codecs, but some things to consider:
1) Why not hard limit upper range of bit rate?
This can be done with vorbis at 22.05 kHz resampling down to a hard upper limit of 35 kbps.
In other words: --resample 22050 -M 35
In order to hard upper limit at 32 kbps, though, resampling has to be done at 16 kHz.
I think it is probably reasonable to set the hard upper limit at 35 kbps. I think most tracks will probably average (as opposed to hard limit) at 32 kbps. I can try the 13 tracks later.
ff123
Are Ayumi's changes even operating in this mode? Why is 22 kHz resampling forced at this bitrate? Maybe 32 kHz would sound better.
I think aoTuV shouldn't be used with any bitrate management options like -b, -m, nor -M. At the present time, he doesn't seem to tune his encoder for using with these options.
Yes, please remember that at bitrates this low even a few kbps deviation from 32kbps (CBR/ABR, or average if we decide to use VBR) will make a large difference to the final output, and file size/bitrate IS very important here, as opposed to when testing files which are targeting a quality, not a bitrate.
Bitrates for 13 tracks using aoTuVb2 --resample 22050 -M 35
27, 29, 33, 32, 31, 32, 34, 33, 31, 34, 32, 33, 32
average is 32
Sound is fluttery, like the official encoder; can probably use either version for the test.
ff123
In a low frequency domain, aoTuV beta2 will bring the same result as 1.0.1. Therefore, for the moment, there is no meaning which turns down 1.0.1 and chooses aoTuV..
In a low frequency domain, aoTuV beta2 will bring the same result as 1.0.1. Therefore, for the moment, there is no meaning which turns down 1.0.1 and chooses aoTuV..
Too bad, because that extra 6 kbps (on average), the resampling at 32 kHz, and your extra quality enhancements makes a big difference in sound quality.
ff123
Dunno the case with speex, but most voice coders fail VERY badly on music and complex sound effects.
Spees does fail "VERY badly" on music, only "badly" ;-) Seriously, at CBR ~34 kbps, it's possible to have recognizable music with Speex, but the quality is definitely not on par with what you'd get for Vorbis. Probably not worth including in this test.
I think Speex belongs to a test dedicated to vocodecs. I already started discussing such test with jmvalin, hopefully he'll have time to conduce it (or someone else might become interested).
Don't have much time to organize it, but I can provide tips on what codecs/settings to use.
I know there are already six encoders being used in this test, and even though this has been the limit in the past would it be possible to include musepack using the telephone preset (quality 2) in this test? It may not be as well supported as the others, but musepack has done suprisingly well in the 64kbps test, maybe it can do well at 32kbps too.
but musepack has done suprisingly well in the 64kbps test
Musepack was not tested in my 64kbps test
@ff123: Thank-you very much for verifying the behaviour of vorbis encodes. That's much appreciated.
... but musepack has done suprisingly well in the 64kbps test ...
On 128 kbps multiformat listening test, but not at 64 kbps (not tested: useless, crap quality).
musepack at 32 kbps might compete... as anchor.
EDIT: Roberto was faster.
Hi guys !
About that idea with speach samples.
I understand, why ITU used them - they all are telephony people and speach is what they usually work on. So their choise is understandable.
This test is stereo audio test, right ?
But speach samples, except some radio plays are mono or pseudo stereo. I think (I may be wrong) that speach stereo samples are very artificial and not that common to specially test them a lot. 2 samples will be enought...
Just my 2 cents
P.S. If we gonna to test mono low bitrate encodings then yes, speach is what we need...
I'm in favor of letting the encoder decide about resampling.
This is perhaps something which would need a pre-test, the performance of SSRCed (22khz? 32khz?) souces vs. original bandwith sources.
As it was pointed out, none of the current Vorbis tunings focus on the managed low bitrate modes, so I'd definetly vote for using the current CVS, which also features the new managed bitrate code (libvorbis I 20031230 - more about it here (http://www.hydrogenaudio.org/forums/index.php?showtopic=17274&hl=vorbis+cbr)).
oggenc --managed -b 30 should be a good cmd.line. I don't think imposing additional restrictions is neccessary when using Vorbis' managed bitrate mode.
dev0
Perhaps this should be two different tests? Streaming speech (e.g. news conferences) and streaming music (internet radio) are quite different beasts. Your choice of codec will very likely depend on the sort of content you're streaming. Speex would not do that well in a music test but would likely win a speech test.
Hey, Ben !!!
"Note the RA8 stereo codec is way better than the RA mono codec, even with mono source."
?????
I'm from Missouri......
Hey, Ben !!!
"Note the RA8 stereo codec is way better than the RA mono codec, even with mono source."
?????
I'm from Missouri......
Just try it. It's the much better "cook" codec. Dramatic difference with most content.
I'm in favor of letting the encoder decide about resampling.
This is perhaps something which would need a pre-test, the performance of SSRCed (22khz? 32khz?) souces vs. original bandwith sources.
As it was pointed out, none of the current Vorbis tunings focus on the managed low bitrate modes, so I'd definetly vote for using the current CVS, which also features the new managed bitrate code (libvorbis I 20031230 - more about it here (http://www.hydrogenaudio.org/forums/index.php?showtopic=17274&hl=vorbis+cbr)).
oggenc --managed -b 30 should be a good cmd.line. I don't think imposing additional restrictions is neccessary when using Vorbis' managed bitrate mode.
dev0
I'm in favor of letting the encoder decide about resampling.
This is perhaps something which would need a pre-test, the performance of SSRCed (22khz? 32khz?) souces vs. original bandwith sources.
We'll definitely need to do some manual tweaking. Some codecs don't do resampling automatically at all, and others offer sub-optimal defaults. The right resampling rate likely will vary with different sources with some content (hence the "high response" RealAudio variants).
So, would CBR or hard-limited max bit rate be a better choice, considering this is a streaming test and that the results should reflect that (and not pseudo-idealized conditions)?
I agree. CBR is the appropriate mode for this test. Note that at least one codec (WMA9) supports a 2-pass mode, which I suggest should be used. That also begs the question of an appropriate buffer size for the CBR encoding - different codecs use different defaults. Some don't allow it to be set. Should we stick with the default (slightly biasing things towards codecs that by default sacrifice latency for compression efficiency), or pick a standard default for codecs that let the value be set? If so, something from 3-6 seconds is probably typical for internet streaming use.
Right. I don't think anyone on his right mind would encode audio to 32kbps at 44.100Hz. I am considering either resampling everything to 22050 (I guess that's what people encoding to this bitrate would do), or letting the encoders choose the appropriate sampling rate.
Well, this is a plausible sample rate for mono HE AAC @ 32 Kbps. I say go for the optimal setting the codec supports. In general, I'm cool with having this be a test of the maximum quality that can be produced within a given compatible bitstream, irrespective of how much encoder tweaking is required to get there.
There will be a slight bias towards codecs/architectures that use a better rate resampler if all our source files are 44.1, but it's not a bias I personally mind .
I have (http://www.rjamorim.com/rrw/qdmc.html) the demo of QDMC Pro 2, that lasts for 15 days. I'll use it for my test.
Just ask QDesign for a NFR review copy. I'm sure they've given me a half-dozen over the years, on different platforms, just for the asking.
Well, this is a plausible sample rate for mono HE AAC @ 32 Kbps.
Yup yup. Both Nero and CT use 44.1khz with 32kbps parametric stereo (mono+HE-AAC+stereo reconstruction information) by default. This also helps pre-echo.
Heh, ok, I didn't want to post this, but I sent this as a PM to Roberto:
Yo dude!
I get 45333bps with my £5 modem, so there... but anyway, I didnt want to write this in the thread, BUT:
I dont know anyone who considers streaming music off the net on dial-up, so this test seems kind of moot if thats the reason for it. As ever, its interesting to see which codec performs best at these rates, but, I find it hard to believe that anyone on dialup would really care about the quality, they know its going to be junk, if they wanted quality, they certainly wouldn't bother.. or care.
I dunno, like I say, its good to see what is the best at 32kbps, but does anyone really care? 48kbps is a bit more interesting, and more of a worthwhile test, in my mind.
Anyway, taraaaaaaaaaaa
Lev-AGE
Afterwards, I thought I may have offended him, as he wanted to catch up with me online. As it turned out, he loved it and begged me to post it up on the forum.... so - here I am.
I'd like to just quickly re-iterate my thinkings in the PM (it wasn't phrased brilliantly, my powers of English are not up to that of an author): Any test of any bitrate is interesting, but
nobody care's about streaming music on 56k.
Heh, ok, I didn't want to post this, but I sent this as a PM to Roberto:
Yo dude!
I get 45333bps with my £5 modem, so there... but anyway, I didnt want to write this in the thread, BUT:
I dont know anyone who considers streaming music off the net on dial-up, so this test seems kind of moot if thats the reason for it. As ever, its interesting to see which codec performs best at these rates, but, I find it hard to believe that anyone on dialup would really care about the quality, they know its going to be junk, if they wanted quality, they certainly wouldn't bother.. or care.
I dunno, like I say, its good to see what is the best at 32kbps, but does anyone really care? 48kbps is a bit more interesting, and more of a worthwhile test, in my mind.
Anyway, taraaaaaaaaaaa
Lev-AGE
Afterwards, I thought I may have offended him, as he wanted to catch up with me online. As it turned out, he loved it and begged me to post it up on the forum.... so - here I am.
I'd like to just quickly re-iterate my thinkings in the PM (it wasn't phrased brilliantly, my powers of English are not up to that of an author): Any test of any bitrate is interesting, but nobody care's about streaming music on 56k.
I'd like to just quickly re-iterate my thinkings in the PM (it wasn't phrased brilliantly, my powers of English are not up to that of an author): Any test of any bitrate is interesting, but nobody care's about streaming music on 56k.
I think people would absolutely like to listen to music at 32 Kbps, it's just that the quality has historically been below entertainment quality. The point of this test is to see how much better things have gotten with modern codecs, and how they compare with past codecs.
Also, even though 32 Kbps audio as stand alone might not be popular today, 32 Kbps audio in a 200 Kbps video/audio stream for low-broadband users is extremely common.
OK, so I'm really at a point where I don't know what to do.
Should I resample all files to a common sampling rate before hand, let codecs resample the stream themselves...
@dev0: For some codecs that would work but for, e.g, WMA, it allows you to choose between 44.1, 32 or 22.05k when encoding to WMA Std. at 32kbps. So, the choice in this case is really up to the person encoding.
Note that at least one codec (WMA9) supports a 2-pass mode, which I suggest should be used.
Unfortunately, it seems WMA 9 only works in two-pass mode down to 64kbps. At least, I couldn't get WMenc9 to do "Bitrate VBR" for bitrates lower than 64.
This is how codecs behave when fed with a 44.100Hz stream:
WMA: Lets you choose what sampling rate
QDesign: Keeps the sampling rate
Real: Keeps the sampling rate. Converts to mono?
Vorbis: Still trying to get it to output 32kbps $%#@!
MP3pro: Seems to only accept 32kbps if in mono Doesn't seem to resample. If I resample beforehand to 32kHz, it accepts 32kbps.
HE-AAC+PS: According to Ivan, won't resample.
So, any idea?
I think that if a codec resamples, you should keep its resampling choice.
For codecs that do not resample, perhaps we should do quick test to check if it would be better to resample (I guess in most cases it would be).
Btw, what will be your low anchor? Lowpassed versions or mp3?
Perhaps this should be two different tests? Streaming speech (e.g. news conferences) and streaming music (internet radio) are quite different beasts. Your choice of codec will very likely depend on the sort of content you're streaming. Speex would not do that well in a music test but would likely win a speech test.
I agree. But there are people using music codecs to stream voice content. I think there is some use to have a handful of speech samples in this test.
I think that if a codec resamples, you should keep its resampling choice.
Problem is, as you noticed, nobody resamples automatically. :/
(I guess in most cases it would be).
I agree.
Btw, what will be your low anchor? Lowpassed versions or mp3?
I'm still considering it. Considering so many people still stream with MP3 at very low bitrates, I guess it could be used as low anchor, and then use lowpass as high anchor.
The sample rate and the bit rate should be the same for all codecs. I realize that this may not show some codecs at their best, but it would keep the playing field level. To be meaningfull, any test such as this needs well defined and strict 'test conditions.' As always, contrary opinions are welcomed. You'll not hurt my feelings.
I'm still considering it. Considering so many people still stream with MP3 at very low bitrates, I guess it could be used as low anchor,
I think that it would be a good comparison point.
For Vorbis use:
oggenc --resample 22050 --managed -b 32
It doesn't seem to accept higher samplerates when working at 32kbps.
Resampling beforehand using ssrc yields a siginificantly higher quality on all samples I tried so far though, so the usage of an external resampler for at least some codecs should be considered (which -again- raises a 'fairness' issue).
The sample rate and the bit rate should be the same for all codecs. I realize that this may not show some codecs at their best, but it would keep the playing field level. To be meaningfull, any test such as this needs well defined and strict 'test conditions.' As always, contrary opinions are welcomed. You'll not hurt my feelings.
I disagree. I believe one should take a single codec at a time and ask: " If I had to use this codec with a 32 kbps upper (hard) limit, what would I do to make the most out of it?". That is what any sensible person should, and hopefully would, do in real life. Considering the broad use of CBR, one should probably not keep hopes too high though...
Maybe the result of this test can inspire some potential users to change to the winning codec/setting from a less optimal one. Hence this might heighten the average quality of streaming content. I think all these tests have an informing as well as educational influence. At least I hope they do.
IMHO a test like this is pretty much useless if it artificially tries to "make it fair". The only reason I see for not choosing the optimal encoding for each codec, would be to show the quality of a widely used (less optimal) setting, compared to what other codecs has to offer.
Apart from plain streaming audio, I imagine a MPEG-4 presentation of e.g. a band with video, audio, pictures and so on, might benefit from such low bitrates to keep the overall size of the mp4 file down. Maybe 32kbps is a little too low, but it would be interesting anyway.
All of this is very much IMHO of course.
For Vorbis use:
oggenc --resample 22050 --managed -b 32
It doesn't seem to accept higher samplerates when working at 32kbps.
oggenc --resample 24000 --managed -b 32
does work for me. That additional kHz frequency response may be beneficial.
oggenc --resample 24000 --managed -b 32
does work for me. That additional kHz frequency response may be beneficial.
I don't think so. Logically, when taking 44.1 kHz material as a starting point, downsampling by a factor 1.8375 would give more (let's call it) rounding errors than by a plain factor 2.
The sample rate and the bit rate should be the same for all codecs. I realize that this may not show some codecs at their best, but it would keep the playing field level. To be meaningfull, any test such as this needs well defined and strict 'test conditions.' As always, contrary opinions are welcomed. You'll not hurt my feelings.
I think you would cripple codecs completely and make test results completely false.
The idea of the test is to show quality of commercially available solutions at their best - not to help "equalize" the results among codecs.
For instance, MP3 would definitely need 22.05 kHz for stereo sound at that bit rate - and some other solution naturally encodes at 44.1 kHz (mp3Pro, High Efficiency AAC) - mp3Pro and HE-AAC can't do 22.05 kHz (actually they could but not on that bit rate and it is useless anyway) - so you're eliminating two codecs immediately.
Fair enough would be to use recommended default settings for each bit-rate, as this is the typical usage scenario - which reflects the biggest number of available streams/content available around.
I agree with Ivan and upNorth. Resampling where no resampling is needed should definetly be avoided.
But some codecs (Vorbis, MP3, WMA etc.) do require resampling. But is it 'fair' to use a high quality SRC tool/implementation like SSRC? Or should each codec's frontend handle the resampling?
In my (very brief) tests with Vorbis the encodes from SSRCed files (44.1->22.05) they sounded significantly (~1 on the ITU scale) better than the ones resampled by oggenc.
Fair enough would be to use recommended default settings for each bit-rate, as this is the typical usage scenario - which reflects the biggest number of available streams/content available around.
I agree completely
I don't think so. Logically, when taking 44.1 kHz material as a starting point, downsampling by a factor 1.8375 would give more (let's call it) rounding errors than by a plain factor 2.
That´s true. However, I assume that really good resamplers don`t introduce severe artifacts even with "odd" resampling-factors (example: 44.1 <-> 48 kHz).
Did a quick test using SSRC and Vorbis:
ABC/HR Version 1.0, 6 May 2004
Testname: Vorbis 32kbps resampling: giveuptheghost-sincealways
1R = dec\giveuptheghost-sincealways.sample18sec.ssrc22.wav
2L = dec\giveuptheghost-sincealways.sample18sec.oggenc24.wav
3R = dec\giveuptheghost-sincealways.sample18sec.ssrc24.wav
4L = dec\giveuptheghost-sincealways.sample18sec.oggenc22.wav
---------------------------------------
General Comments:
---------------------------------------
1R File: dec\giveuptheghost-sincealways.sample18sec.ssrc22.wav
1R Rating: 2.5
1R Comment:
---------------------------------------
2L File: dec\giveuptheghost-sincealways.sample18sec.oggenc24.wav
2L Rating: 1.8
2L Comment:
---------------------------------------
3R File: dec\giveuptheghost-sincealways.sample18sec.ssrc24.wav
3R Rating: 2.3
3R Comment:
---------------------------------------
4L File: dec\giveuptheghost-sincealways.sample18sec.oggenc22.wav
4L Rating: 1.4
4L Comment:
---------------------------------------
ABX Results:
Seems like the samplerate used is a lot less important than the SRC tool used.
And another quick one:
ABC/HR Version 1.0, 6 May 2004
Testname: Vorbis 32kbps resampling: eaves-teenagelifesentence
1R = dec\eaves-teenagelifesentence.sample17sec.ssrc22.wav
2R = dec\eaves-teenagelifesentence.sample17sec.oggenc22.wav
3L = dec\eaves-teenagelifesentence.sample17sec.ssrc24.wav
4R = dec\eaves-teenagelifesentence.sample17sec.oggenc24.wav
---------------------------------------
General Comments:
---------------------------------------
1R File: dec\eaves-teenagelifesentence.sample17sec.ssrc22.wav
1R Rating: 2.1
1R Comment:
---------------------------------------
2R File: dec\eaves-teenagelifesentence.sample17sec.oggenc22.wav
2R Rating: 1.2
2R Comment:
---------------------------------------
3L File: dec\eaves-teenagelifesentence.sample17sec.ssrc24.wav
3L Rating: 1.9
3L Comment:
---------------------------------------
4R File: dec\eaves-teenagelifesentence.sample17sec.oggenc24.wav
4R Rating: 1.5
4R Comment:
---------------------------------------
ABX Results:
The differences between the ssrced 22050 and 24000 versions are sublte, but I perceive the 22.05khz one as less artifacted. Maybe somebody could verify that (I used fb2k's SSRC Resampler in 'Slow Mode' and foo_clienc).
cmd.line: oggenc --managed -b32 [--resample #]
Sample: eaves-teenagelifesentence.sample17sec.flac (http://dev0.rc55.com/files/samples/eaves-teenagelifesentence.sample17sec.flac)
I used the official 1.0.1 binary from Vorbis.com.
Given that oggenc uses (last time I looked) bandlimited sinc interpolation, which is a fine algorithm, I think this is a bug or bad tuning of the parameters.
Would lowpassing be considered fair? It seems as though I can convince AoTuV down to 32kb and below using the lowpass settings in OggDropXPd.
I would agree with Lev that a 40 or 48kbs test would be more interesting. I admit I had a top rate ISP, but I averaged just under the 50000bps mark most weekends back in the dark ages when I had a modem
Fair enough would be to use recommended default settings for each bit-rate, as this is the typical usage scenario - which reflects the biggest number of available streams/content available around.
I agree completely
Well this would mean also using the internal Vorbis resampler. If it's not as good as external SSRC, then it's a problem in the encoder, and too bad if it's not fixed.
However, I think that Vorbis supporters wouldn't like that, if an external component like SSRC can make Vorbis sound better in this test.
Another question is, is it fair to use external components here.
Did a quick test using SSRC and Vorbis:
(...)
Seems like the samplerate used is a lot less important than the SRC tool used.
That's very interesting. Thank-you for testing it.
OK, so the codecs list would now be:
- Ahead HE AAC + PS at 32kbps, 44.1kHz
- Ogg Vorbis 1.0.1CVS at managed bitrate 32kbps, resampled with SSRC to 22050Hz
- MP3pro 32kbps, resampled to 32kHz
- QDesign 32kbps at either 44.1 or 32kHz
- WMA Std 32kbps at either 44.1, 32 or 22.5kHz
- Real Audio Cook 32kbps at either 44.1, 32 or 22.5kHz
- Low anchor: MP3 at 32kbps, 12kHz
- High anchor: lowpass
What do you guys think?
Regards;
Roberto.
Another question is, is it fair to use external components here.
I believe it is. This test's scope is to compare streaming audio. Streaming stations use external components for several purposes. So I think it's fair if I use these components, if that leads to improved quality - what the stations are ultimately after.
Fair enough would be to use recommended default settings for each bit-rate, as this is the typical usage scenario - which reflects the biggest number of available streams/content available around.
I agree completely
Well this would mean also using the internal Vorbis resampler. If it's not as good as external SSRC, then it's a problem in the encoder, and too bad if it's not fixed.
However, I think that Vorbis supporters wouldn't like that, if an external component like SSRC can make Vorbis sound better in this test.
Another question is, is it fair to use external components here.
You have a point here, but I don't think is fair to use external tools in this test mainly because I don't imagine the "average joe" using them to get the best quality.
[edit] Ok rjamorim cleared this in the previous post
[/edit]I'd like to test both version of the sample (the original one, eventually resampled by internal resampler versus the one SSRCed): it would double the amount of samples in the test, but is should still remain "doable" since the low bitrate makes abx easier (?).
You have a point here, but I don't think is fair to use external tools in this test mainly because I don't imagine the "average joe" using them to get the best quality.
Well, I personally don't think the average joe would use 32kbps for his daily encodings :B
I'd like to test both version of the sample (the original one, eventually resampled by internal resampler versus the one SSRCed): it would double the amount of samples in the test, but is should still remain "doable" since the low bitrate makes abx easier (?).
That would be difficult. We already have 8 samples. Even though testing is easy at this bitrate, so many samples require several iterations so that you can decide what sample sounds better than the other.
I'd like to test both version of the sample (the original one, eventually resampled by internal resampler versus the one SSRCed): it would double the amount of samples in the test, but is should still remain "doable" since the low bitrate makes abx easier (?).
I'd rather do more tests beforehand. I only quickly tested two (very similiar) samples, the results could be less dramatic for other types of music.
With more SSRC vs. <encoder's resampler> test results it should be easier to weight 'ease of use' against 'best quality'.
Real word question: How many broadcasting tools (Oddcast?) use their own resampler? How many don't?
Is it possible to do live streaming with SSRC+Vorbis encoding option with currently available tools?
I think this is a pretty essential question regarding whether external SSRC could be fairly used with Vorbis here.
Can't streaming servers resample the WAVs with SSRC beforehand and then feed them to oddcast?
Couldn't one of the excellent Vorbis fork authors simply make a niche branch of Vorbis which replaces the internal resampler with SSRC. This would remove the need for this particular argument
Can't streaming servers resample the WAVs with SSRC beforehand and then feed them to oddcast?
With live content, I don't know.
With live content, I don't know.
Oh, but I'm not testing live content. It's all prerecorded stuff
With live content, I don't know.
Oh, but I'm not testing live content. It's all prerecorded stuff
Ok, it's just that you said: "Streaming stations use external components for several purposes. So I think it's fair if I use these components, if that leads to improved quality - what the stations are ultimately after."
I think many radio stations are/will be streaming live content, be it Vorbis, wma, AAC-PS (or Digital Radio Mondiale) etc.
I'm all for a 32kbps test, and not a 48kbps one.
We would see how some of these codecs fare at or near the bottom of their range. Some (http://www.coolblue.co.nz/) sites are streaming at even lower rates of 16kbps, admittedly usually mono.
Streamed video will usually include audio at this lower rate as well.
I expect that most of the codecs will lowpass automatically, so there should be no decision making about whether to lowpass or not. However, should we lowpass beyond the encoder's defaults (Ivan is suggesting not to)? Where there is choice offered by an encoder (and not just one default), I say we make the choice ourselves. We could run a few pre-tests to see how some of the (more flexible) encoders fare at various lowpass frequencies. There should be an obvious point where we select for frequency content versus artifact content.
Just something I would like confirmed at this point: this is a stereo test, isn't it?
edit: looks like my reply took some while and several replies got in before me.
I think many radio stations are/will be streaming live content, be it Vorbis, wma, AAC-PS (or Digital Radio Mondiale) etc.
Well, if we are to emulate live stations, we can sack HE AAC+PS right away, because so far there's no way to stream it ATM, live or not (DRM equipment still only broadcasts HE AAC).
I think many radio stations are/will be streaming live content, be it Vorbis, wma, AAC-PS (or Digital Radio Mondiale) etc.
Well, if we are to emulate live stations, we can sack HE AAC+PS right away, because so far there's no way to stream it ATM, live or not (DRM equipment still only broadcasts HE AAC).
Well, ok. If the live streaming concept is ditched, then of course anything is possible I suppose. DRM with PS should be ready anytime, but IIRC the PS-part is a bit different than in the MPEG standard. I'm not sure but FhG&CT might have a streaming solution in principle ready which does AAC-PS.
I'm not trying to ditch encoders that have no streaming support.
My point here is that I'm trying to cut some slack to the encoders. I'm not interested in conducing a test as anal as it has been suggested here, because my test isn't even a formal one for starters.
If we are to start wildly speculating that "FhG and CT might have a streaming solution ready", we can also wildly speculate that Monty will have a fixed version of oggenc soon.
Heh, you are right. To me it just sounds questional in a principle level to use external component to compensate for a non-optimized feature in an encoder.
This problem would be solved if somebody would actually make a Vorbis binary with better resampling.
But fixing this using an external component instead of the encoder's own component in order to gain better quality for the test, it is in the limit imo..
What do other people think?
So you're now setting limits
I'm not setting any limits. I said in my opinion it is in the limit (of what should be allowed when testing encoders).
I personally would draw the line to the point where totally separate external components are used to replace the encoder's internal component in order to compensate for an encoder software's deficiency.
Well, if we are to emulate live stations, we can sack HE AAC+PS right away, because so far there's no way to stream it ATM, live or not (DRM equipment still only broadcasts HE AAC).
DRM equipment broadcasts HE-AAC streams with Parametric Stereo since December 2003.
Well, if we are to emulate live stations, we can sack HE AAC+PS right away, because so far there's no way to stream it ATM, live or not (DRM equipment still only broadcasts HE AAC).
DRM equipment broadcasts HE-AAC streams with Parametric Stereo since December 2003.
Since before it was even standardized?
Well, if we are to emulate live stations, we can sack HE AAC+PS right away, because so far there's no way to stream it ATM, live or not (DRM equipment still only broadcasts HE AAC).
DRM equipment broadcasts HE-AAC streams with Parametric Stereo since December 2003.
Since before it was even standardized?
New DRM standard for audio coding was finalized December 15 2003 and this already included PS AAC.
All transmitters switched to PS AAC shortly afterwards. (Sometimes mono is still used when the propagation is very bad to save a few more bits).
Is it possible to do live streaming with SSRC+Vorbis encoding option with currently available tools?
I think this is a pretty essential question regarding whether external SSRC could be fairly used with Vorbis here.
I just checked: It's possible using (who would've guseed) using foobar2000 and foo_oddcast.
It should also be possible using ssrc and ices (http://www.icecast.org/ices.php) on a *nix system
I just checked: It's possible using (who would've guseed) using foobar2000 and foo_oddcast.
It should also be possible using ssrc and ices (http://www.icecast.org/ices.php) on a *nix system
oh, well, cheers. It's settled then. I'll use SSRC with Vorbis.
Thanks for checking it out, dev0.
Now, it only remains to be tested what sampling rates will be used with WMA and Real. Maybe I should set up a really simple and quick pre-test?
Uh, OH ! "My domain" listening test, finally.
1. 32 Kbps is enough for modems. Anyway i think you shouldn't focus on bandwidth only, but balancing it on listening quality too. I mean that you should consider to downsample (SSRC, obviously) files to 32 KHz for mono or 22 KHz for stereo... (i prefer mono 'cause stereo image is not so important for internet radio due to speaker's speech, and no DRM needed).
2. About samples: don't use only speech or single instrument samples.
Real world internet radios streams so mutch different styles of music that you should consider at least 9 - or more - generes (world, classical, jazz, pop, dance, electronic, progressive, extreme metal).
I can provide interesting world and extreme metal samples, if you need (check out this file (http://www.angelfire.com/band2/vc_fan_page/Vomitorial_Corpulence_Skin_Stripper_Christ_Is_The_Demon_Crusher_Track27.mp3), to get an idea - interesting spectrum, isn't it ?)
I personally have high hopes for HE-AAC+PS at 32kbps - even in stereo. Months ago when the HE-AAC encoder first came out I did some test HE-AAC 32kbps material and was very impressed, sounded especially good with synthetic music. (dance, etc.) Unfortunately I haven't been able to test it recently as Nero has begun producing very strange sounding .mp4's (sped up, weird crackling all through it, just whack sounding) on my system even after a clean virgin win2k install + nero latest version...but yes with PS I can imagine it will be quite good.
Low anchor: MP3 at 32kbps, 12kHz
If the mp3 enchor is Lame, I'd suggest letting it use its default sampling rate.
Example: at 32kbps, the lowpass is around 5.5kHz, but the sampling rate is 16kHz and not 12kHz. The sample rate used by Lame is determined automatically in order to avoid use of sfb21. By using a 12kHz rate, Lame would have to use the problematic sfb21.
Now, it only remains to be tested what sampling rates will be used with WMA and Real. Maybe I should set up a really simple and quick pre-test?
In Real the samplerates are forced by the flavor. If your input is a another samplerate it gets resampled automatically. You have only two flavors (20 and 21) with 32kbps, one with 22050 Hz and one 44100 Hz. You cannot use another samplerate.
If the mp3 enchor is Lame, I'd suggest letting it use its default sampling rate.
I was considering FhG, since it's believed FhG offers better quality at low bitrates.
If people prefer I use Lame, I will use it instead.
In Real the samplerates are forced by the flavor. If your input is a another samplerate it gets resampled automatically. You have only two flavors (20 and 21) with 32kbps, one with 22050 Hz and one 44100 Hz. You cannot use another samplerate.
That's interesting. I never saw these "flavors" in Real Producer. Where can I reach them?
I'm looking forward to this test because results would also be useful for ultra-low bitrate dvd backups, so 32kb/s does look as the common bottom for all these codecs. I use 64 bit HE-AAC for my movies and it sounds really good while still small, ill test ps whenever nero releases the new version and i could try 56, as stated in the last test.
So my hopes are also with HE-AAC+PS.
Allow me to ask something dumb but quick, theres no point on using parametric stereo on mono files right?? just to be sure
If the mp3 enchor is Lame, I'd suggest letting it use its default sampling rate.
I was considering FhG, since it's believed FhG offers better quality at low bitrates.
If people prefer I use Lame, I will use it instead.
In Real the samplerates are forced by the flavor. If your input is a another samplerate it gets resampled automatically. You have only two flavors (20 and 21) with 32kbps, one with 22050 Hz and one 44100 Hz. You cannot use another samplerate.
That's interesting. I never saw these "flavors" in Real Producer. Where can I reach them?
That's interesting. I never saw these "flavors" in Real Producer. Where can I reach them?
The 44.1 versions are the "High Response" versions.
I'd say that with more sources than not, the non-High Response versions sound better. But there are plenty of exceptions.
Allow me to ask something dumb but quick, theres no point on using parametric stereo on mono files right?? just to be sure
Seems that yes. Mono file will use SBR only...
EDIT:
So my hopes are also with HE-AAC+PS.
Still unsure after test of samples that Garf provided. Seems that it will sound better than anything else on such a bitrates, but not sufficient for DVD backup... Sometimes it poduce ugly result. The only hope is that sound in movie is much less complex than music...
BTW, about 56Kbit you mentioned, As I understand Garf posts, new HEAAC encoder will produce 56Kbit stream with a similiar quality to current 64Kbit... They claim that HEAAC is avanced a lot in their encoder... Have to wait and test for myself
That's interesting. I never saw these "flavors" in Real Producer. Where can I reach them?
Did you never used Helix Producer? It´s the completly free RealMedia CLI-encoder for Windows, Linux and Mac. It´s even open-source (only the application, not the codecs). Here you can use all advanced features and change special options you don´t see in the other tools, but in fact these flavors are used everywhere, they are also stored in the output file, but in the more easy to use tools you cannot see them, but each audio option in this drop-down list with the bitrates represents one flavor.
You can download Helix-Producer here: https://helix-producer.helixcommunity.org/downloads.htm (https://helix-producer.helixcommunity.org/downloads.htm)
For a list of all currectly used codecs with all flavors etc.: https://producerapps.helixcommunity.org/cmd...io_Codec_Tables (https://producerapps.helixcommunity.org/cmdproducer/docs/AudienceFile.htm#Audio_Codec_Tables)
Note: This list is not complete and aac flavors are not correct, I have a file called "AudienceDefaults.xls" containing all ever used codecs, but in there reordered website I cannot find it anymore, also it is not up-to-date, the aac codecs are missing.
Thank-you for the information, benwaggoner and S_O
Yes, I already used Helix Producer, but I prefer to work on Real Producer's GUI
Here's a little favour I would like to ask from you guys:
I uploaded 4 samples encoded to WMA 32kbps at 22.050, 32.000 and 44.100Hz. This is a little pre-test to try to find out at what sampling rate WMA sounds best.
The sample packages are here:
http://www.rarewares.org/samples/ (http://www.rarewares.org/samples/)
Testing them shouldn't take more than 5 minutes. Download the package, unzip it, unflac the samples, load them on ABC/HR or ABC/HR Java (the sample with no _X at the filename is the reference), and post the results file (no need to ABX, the samples should sound plenty bad anyway ).
Thank-you very much for helping. Tomorrow I'll probably conduce another quick test with Real Audio or QDesign.
How I created those samples: I loaded the WAV files on Windows Media Encoder 9 (probably the crappiest piece of software I've ever found), saved them to 32kbps (either 44.1, 32 or 22.05kHz), decoded the WMAs with dbpoweramp, converted all samples to 44.1kHz with SSRC HP (to avoid problems related to bad sound card resamplers) and FLACd.
Best regards;
Roberto.
I don't know what was worse.....waiting for the samples to download on my crappy 20kbps dialup, or actually listening to them In any case, I'll post results for the others as I test them.
Overall, I must mention that I do already have a personal preference when it comes to low-bitrate audio: the duller sound of lowpassed or downsampled audio is much preferred over the ringing, lispy artifacts one finds with higher sampling rates and/or lowpasses. Thus, I didn't find the two low sampling rate clips to be terribly annoying, but close in quality to MW radio. At these ultra-low bitrates, sound quality might be a function of personal preference, since all these samples are quite bad from a quantitative perspective, but yet are qualitatively quite different. Some might prefer WMA's metallic HF artifacts to MP3's very sharp lowpass or Vorbis' collapsed stereo image; it's simply a matter of personal taste. I've listened to ballgames on AM radio for over 20 years, so that type of sound is preferred for me, and thus my ratings might be higher for dull samples than others may report.
ABC/HR for Java Version 0.4b, 26 June 2004
Testname: Female Speech @ 32kbps
1R = /Users/Angelo/Desktop/female_speech/female_speech_2.wav
2L = /Users/Angelo/Desktop/female_speech/female_speech_1.wav
3R = /Users/Angelo/Desktop/female_speech/female_speech_3.wav
---------------------------------------
General Comments: Sample 2 is horrible; tons of pre and post-echo. Speech intelligible but annoying.
---------------------------------------
1R File: /Users/Angelo/Desktop/female_speech/female_speech_2.wav
1R Rating: 1.5
1R Comment: Extremely annoying pre and post-echo. Speech is still intelligible, but unpleasant to listen to.
---------------------------------------
2L File: /Users/Angelo/Desktop/female_speech/female_speech_1.wav
2L Rating: 3.5
2L Comment: Duller than sample 2, but much more pleasant to listen to. Definitely less noticeable artifcating than aforementioned sample.
---------------------------------------
3R File: /Users/Angelo/Desktop/female_speech/female_speech_3.wav
3R Rating: 3.5
3R Comment: Not sure that I can hear a difference between this and Sample 1.....dull because of lower sampling rate, but still listenable.
---------------------------------------
Ok....here's the results for the Kraftwerk sample. Again, two of the samples are very close, if not the same to me in terms of sound quality, and I'm not sure if I can really hear a difference between the two (in lieu of ABX). The remaining sample is, like with the female speech sample, unbearably awful....classic WMA sound, I would say
ABC/HR for Java Version 0.4b, 26 June 2004
Testname: Kraftwerk @ 32kbps
1R = /Users/Angelo/Desktop/kraftwerk/kraftwerk_1.wav
2L = /Users/Angelo/Desktop/kraftwerk/kraftwerk_3.wav
3R = /Users/Angelo/Desktop/kraftwerk/kraftwerk_2.wav
---------------------------------------
General Comments:
---------------------------------------
1R File: /Users/Angelo/Desktop/kraftwerk/kraftwerk_1.wav
1R Rating: 3.0
1R Comment: Dull; attacks much less sharp than reference (pre-echo), but not horribly annoying.
---------------------------------------
2L File: /Users/Angelo/Desktop/kraftwerk/kraftwerk_3.wav
2L Rating: 3.2
2L Comment: Dull, but maybe a little more HF than sample 1? Very close to sample 1, not sure if there is a real difference.
---------------------------------------
3R File: /Users/Angelo/Desktop/kraftwerk/kraftwerk_2.wav
3R Rating: 1.3
3R Comment: Awful pre and post echo....artifacts before and after attacks. Worst of bunch by far.
---------------------------------------
Well, it looks like no more testing for tonight....ABC/HR (Java version since I'm on a *nix system) suddenly went flakey on me. Although I was able to set up two new tests earlier, the program will not open that option, or load any saved configurations (it simply does nothing when those options are clicked upon). I even unzipped a fresh copy, restarted the computer, and cleared out my Java cache, all to no avail! What's wrong here? (I'm using Darwin w/ OS X 10.3.4 and Java 1.4.2).
(My apologies for going OT).
[span style='font-size:8pt;line-height:100%']
ABC/HR Version 1.0, 6 May 2004
Testname: Bartok_strings2
Tester: ff123
1R = D:\junk\pretest\Bartok_strings2_3.wav
2L = D:\junk\pretest\Bartok_strings2_2.wav
3R = D:\junk\pretest\Bartok_strings2_1.wav
---------------------------------------
General Comments:
pretty much rated by lowpass
---------------------------------------
1R File: D:\junk\pretest\Bartok_strings2_3.wav
1R Rating: 1.8
1R Comment:
---------------------------------------
2L File: D:\junk\pretest\Bartok_strings2_2.wav
2L Rating: 3.4
2L Comment:
---------------------------------------
3R File: D:\junk\pretest\Bartok_strings2_1.wav
3R Rating: 2.5
3R Comment:
---------------------------------------
ABX Results:
ABC/HR Version 1.0, 6 May 2004
Testname: female_speech
Tester: ff123
1L = D:\junk\pretest\female_speech_1.wav
2R = D:\junk\pretest\female_speech_2.wav
3R = D:\junk\pretest\female_speech_3.wav
---------------------------------------
General Comments:
---------------------------------------
1L File: D:\junk\pretest\female_speech_1.wav
1L Rating: 2.5
1L Comment:
---------------------------------------
2R File: D:\junk\pretest\female_speech_2.wav
2R Rating: 2.0
2R Comment: higher frequencies more apparent, but so is additional noise pumping
---------------------------------------
3R File: D:\junk\pretest\female_speech_3.wav
3R Rating: 2.5
3R Comment:
---------------------------------------
ABX Results:
ABC/HR Version 1.0, 6 May 2004
Testname: kraftwerk
Tester: ff123
1L = D:\junk\pretest\kraftwerk_1.wav
2R = D:\junk\pretest\kraftwerk_3.wav
3L = D:\junk\pretest\kraftwerk_2.wav
---------------------------------------
General Comments:
---------------------------------------
1L File: D:\junk\pretest\kraftwerk_1.wav
1L Rating: 2.3
1L Comment:
---------------------------------------
2R File: D:\junk\pretest\kraftwerk_3.wav
2R Rating: 2.9
2R Comment: sharpest attacks
---------------------------------------
3L File: D:\junk\pretest\kraftwerk_2.wav
3L Rating: 2.9
3L Comment: best frequency response; can't choose between the attacks or the frequency response on this particular sample
---------------------------------------
ABX Results:
ABC/HR Version 1.0, 6 May 2004
Testname: waiting
Tester: ff123
1L = D:\junk\pretest\Waiting_1.wav
2R = D:\junk\pretest\Waiting_3.wav
3L = D:\junk\pretest\Waiting_2.wav
---------------------------------------
General Comments:
typical wma ringing sound in the background
---------------------------------------
1L File: D:\junk\pretest\Waiting_1.wav
1L Rating: 2.0
1L Comment:
---------------------------------------
2R File: D:\junk\pretest\Waiting_3.wav
2R Rating: 2.3
2R Comment:
---------------------------------------
3L File: D:\junk\pretest\Waiting_2.wav
3L Rating: 2.8
3L Comment: strongest ringing, but also best frequency response.
---------------------------------------
ABX Results:
[/span]
How about a sample which is middle of the road as far as encoding difficulty goes, but still has substantial high frequencies in it? Like a jazz piece.
ff123
Well, it looks like no more testing for tonight....ABC/HR (Java version since I'm on a *nix system) suddenly went flakey on me. Although I was able to set up two new tests earlier, the program will not open that option, or load any saved configurations (it simply does nothing when those options are clicked upon). I even unzipped a fresh copy, restarted the computer, and cleared out my Java cache, all to no avail! What's wrong here? (I'm using Darwin w/ OS X 10.3.4 and Java 1.4.2).
(My apologies for going OT).
First make sure that you're not trying to open a saved
session as a config file, or vice-versa, that you didn't save a config file as a session.
ff123
First make sure that you're not trying to open a saved session as a config file, or vice-versa, that you didn't save a config file as a session.
ff123
No; after I deleted the unzipped folder and created a new one, I had no saved files to open, so I can't recreate that particular problem. My main concern is that when I click on "setup test." absolutely nothing happens...no dialog box, nothing. I'm not sure as to why this
How about a sample which is middle of the road as far as encoding difficulty goes, but still has substantial high frequencies in it? Like a jazz piece.
ff123
Something off of Miles Davis'
Bitches' Brew from 1969 might do the trick. The remastered version has a lot of HF content and tape hiss, but the percussion is not the centerpiece of the record. Tracks like "Miles Runs the Voodoo Down" feature sections without a lot of trumpet (like after the 4" mark), which would be somewhere in the middle of encoding complexity. The only problem we might encounter with jazz is stereo seperation; many of the older jazz albums I own have very pronounced stereo seperation (like Bitches Brew and Time Out), which will almost certainly cause problems for encoders at such meager bitrates.
How about a sample which is middle of the road as far as encoding difficulty goes, but still has substantial high frequencies in it? Like a jazz piece.
Unfortunately, there has been very few interest in this small pre-test, so I guess there is no point in expanding the sample choices.
Thank-you very much, Cygnus X1 and ff123, for helping.
The samples were:
_1 - 22050Hz
_2 - 32000Hz
_3 - 44100Hz
I wonder what to do now. Cygnus clearly hated _2 on the files he tested, and ff123, OTOH, in some cases (Waiting, Bartok) preferred it.
The (few) results received are inconclusive, unfortunately.
How about a sample which is middle of the road as far as encoding difficulty goes, but still has substantial high frequencies in it? Like a jazz piece.
Unfortunately, there has been very few interest in this small pre-test, so I guess there is no point in expanding the sample choices.
Thank-you very much, Cygnus X1 and ff123, for helping.
The samples were:
_1 - 22050Hz
_2 - 32000Hz
_3 - 44100Hz
I wonder what to do now. Cygnus clearly hated _2 on the files he tested, and ff123, OTOH, in some cases (Waiting, Bartok) preferred it.
The (few) results received are inconclusive, unfortunately.
I think middle of the road will favor 32 kHz sampling for the higher frequency response. That's also where the majority of music will lie.
Interesting that 44.1 kHz sampling has less high frequency response than 32 kHz sampling. I wonder why that is?
ff123
Hello.
Ivan sent me the AAC encoder that will be available in next Nero release, featuring that stereo enhancement technique. I'm posting it here for peer review before the test starts:
http://pessoal.onda.com.br/rjamorim/nero_aac.zip (http://pessoal.onda.com.br/rjamorim/nero_aac.zip) (909Kb)
The interface is the same as before but, according to Ivan, that enhancement technique kicks in at 32kbps CBR and lower when using HE AAC. I don't know about VBR profiles using this technique.
Test should start in 24-30 hours.
Best regards;
Roberto.
Nero AAC Codec 2.9.9.95
It´s nice to have the latest AAC encoder without having to download 30MB
Is "Downnsampled SBR" already avaible in this release? I don´t think so because I cant´t select HE-AAC when choosing a bitrate of 128kb/s.
Hi, just a few reminders.
Dialup modems using v.90 can't send faster than 33.6kbps. v.92 allows a tiny little bit more if line conditions allow, something like 40kbps.
For .v9x to work, there needs to be a digital isdn like thingie at the other end (eg. ISP), otherwise you are stuck at v.34 (33.6kbps max bi-dir). It is not uncommon for modems to throttle down when line noise increases.
You also have to accomodate for protocol overhead (v.xx+ppp+tcp, etc). There is a little help with the use of realtime lzw compression (around 4:1 for text). On the other hand, too many people nowdays use softmodems, which tie the cpu since the whole modulation demodulation is done in software. This cause too many unexpected issues, be lucky if it works at all..
So i think 32kbps should be the maximun intended bitrate for dialup modems. Some people may get thru with a little more, but not all. In fact, sometimes establishing a 33.6kbps link can be difficult, 31.2, 28.8 and 26.4 are not uncommon connect rates.
Also, i am one of those people who favored ogg vorbis instead of speex for mostly speech based content. After many tests, my reasoning is this:
Yes, for the same bitrate, the speech codecs can make the voice sound better, BUT, add something else in the content (hand clap, second voice, instruments, street noise, etc, etc, etc), and a major artifact will come, often distorting the main voice. When using a non speech codec, it may have an overall reduced quality, but this quality tends to remain stable (ie, not suddendly adding very annoying artifacts).
With Ogg Vorbis, streaming an AM radio (live) just using -q-1 and --resample 8000 (mono) i get a very listenable landline telephone like quality, averaging around 9kbps with peaks never exceeding 12kbps. I have set up a test stream you can access here (spanish language) http://mipagina.cantv.net/artemis3/radio/ (http://mipagina.cantv.net/artemis3/radio/)
I understand this is not the fault of the speech codecs, they were just intended for other things.
This will be an interesting test, and most ppl can participate
Hello.
Ivan sent me the AAC encoder that will be available in next Nero release, featuring that stereo enhancement technique. I'm posting it here for peer review before the test starts:
http://pessoal.onda.com.br/rjamorim/nero_aac.zip (http://pessoal.onda.com.br/rjamorim/nero_aac.zip) (909Kb)
The interface is the same as before but, according to Ivan, that enhancement technique kicks in at 32kbps CBR and lower when using HE AAC. I don't know about VBR profiles using this technique.
Test should start in 24-30 hours.
Best regards;
Roberto.
umm so ps isnt going to be available at say... 56kb/s?? i thought the test with the samples showed good results between 56ps vs 64 non-ps, is it just me? Also was the quality tuned for portable preset? i want to know if its worth to reencode my portable files and if the same applies even for transparent preset...
btw, i tried to select the downmix to mono option and it crashed
thnx in advance
quick test:
mono file was tested and i couldnt abx, was raw he-aac tuned at this bitrate? (tape preset, in mono around 16kbps)
Dumbly, i overwrote the dlls and a sample i had before ps so i cant test the before ps encoder anymore, cbr vs cbr. anyway i encoded a stereo file in tape preset and also in cbr 32kbps and tried to compare em, conclusion: my ears are crap, thats why i dont participate ever in tests didnt notice difference, the only way i can tell difference is between diferent bitrates or resolutions lol, or maybe ps also works in tape preset now?? dunno
umm so ps isnt going to be available at say... 56kb/s??
Something like this:
http://www.hydrogenaudio.org/forums/index....ndpost&p=219314 (http://www.hydrogenaudio.org/forums/index.php?showtopic=22270&view=findpost&p=219314)
EDIT:
i thought the test with the samples showed good results between 56ps vs 64 non-ps, is it just me?
You mean that Garf samples ?
If yes: only one of that 3 was PS, two others were HE
No no - this encoder has "old" VBR - it is the same as in previous version (we are still working on the new one) - so nothing changed there. "Tape" preset is pure HE-AAC.