99% of HA community are on the same page that codec should be tested without any bitrate restriction while produce the same bitrate on enough big amount of files.

What is your personal opinion how big amount of files is neccessary to make encoders produce same avarage bitrate after 30' second? Test samples are likely to be short and this can particulary be a reason to get biased bitrates.

What is your personal opinion how big amount of files is neccessary to make encoders produce same avarage bitrate after 30' second? Test samples are likely to be short and this can particulary be a reason to get biased bitrates.

Now, IIRC, at ~128 kbs, all encoders should run at 44.1 kHz by default, am I right? So if we take that bitrate, the sampling rate issue should disappear.

Chris

Oh, I forgot: Who says the number of encoding parameters needs to equal the number of data elements? Even something such as the decision whether to use short blocks or a long block already requires a handful of parameters.

Now, IIRC, at ~128 kbs, all encoders should run at 44.1 kHz by default, am I right? So if we take that bitrate, the sampling rate issue should disappear.

That was 55 CDs of classical music. You know what that means. With Q 59 and 55 CDs of 'emesesk' music you end up in the 140-145kbit/s range. And beginning from the next smaller setting, Q 58, downsampling is the default for Quicktime. So no, depending on the encoded content you are not right. But since it seems we won't individually alter Q values to get each track as close to ~128kbit/s as possible, anyway, it might not really matter. Depending on the selection of samples, the global Q value might be higher than 59 and then downsampling is really not an issue.

I have 87 lossless cross-genre albums on my notebook right now. I'll check in a couple of minutes how close its average is going to get to 128kbit/s at Q 59.

PS I have finished the 87 albums. I get a collection average of 129 kbit/s (median at 134 kbit/s) for Q 59. Biggest surprise is the MFSL edition of "A Night in Tunesia" by Art Blakey and the Jazz Messengers from 1960, with an album average of 164 kbit/s. On the low end are Miles Davis recordings from the 50s with ~72kbit/s average.

I'm testing different "target" bitrate settings for the CVBR mode right now on the same set. It's not exactly a target bitrate, because the constraint seems to be enforced asynchronously. It rather behaves as "don't fall below that bitrate on average and scale up moderately when required". So I expect the matching target for CVBR to be in the range of 117-120 kbit/s. I'm verifying this right now, but it needs some time, since about 30GB need to be processed in each run.

If someone else could experiment with Nero AAC q values, that would be great. I'm willing to test that result against the 87 CD set. But since it is kind of slow over VMware, I can't do the experimenting myself.

Jazz is a little overrepresented, but it spans music from six decades with great variety, so I think it's ok.

I found it very interesting that the bitrate distribution is quite different for CVBR, which I did not expect to that degree. Art Blakey doesn't lead anymore (now 133kbit/s), but Boulez: Répons at 136kbit/s. The lowest is now Radiohead with "Motion Picture Soundtrack" from Kid A at 83kbit/s (TVBR 86kbit/s), but there are only 4 tracks below 100kbit/s at all! The median is at 130kbit/s.

If I would plot a graph of the results, the edges would be very steep for CVBR, only very few tracks are found at the extremes, most form a flat top in the middle.

For TVBR, even though the bitrates goes up as high as 168 kbit/s, there are very many tracks both at the upper and the lower end and pretty equal distribution over the whole (though much larger) bitrate range.

Quicktime on the Mac doesn't have any problem with odd bitrates, it's rather a bug of the Windows port. Both nao's XLD and Apple's afconvert front-end don't have this problem.

If your system cannot encode 121 kbit/s, then try even numbers as 120 and 122. You will see, they produce different file sizes.

PS Quicktime's CVBR target bitrate, is a minimum average, not a real target, as described above. If we compare TVBR 60 against CVBR 128, we will give CVBR an unfair advantage of up to 5% without necessity. Much of TVBR's efforts to save bitrate on non-complex passages would be superseded.

PPS What do you think have I done the whole day? Encode several times 30GB, at different CVBR settings, just to get the same result each time?

So what means are you guys using for measuring and calculating the average bitrates? Can the bitrates that programs report be blindly trusted?

I tried demuxing MP4/M4A to raw AAC with Yamb/MP4Box, but surprisingly that actually increased the file size a bit. Perhaps MP4 somehow packs the stream more effectively and the despite the additional MP4 container structure the overall file size can be smaller than the size of the raw stream.

Could the AAC developers explain how AAC is stored in the container and how the bitrate values are saved in the "atoms"? Does the MP4 container structure have a defined size overhead that can be detected or calculated?

Could someone give a summary to what has been decided so far? Is the discussion about codecs and their settings over? I am asking because there was already a samples thread somewhere and usually you choose samples after choosing codecs (at least it was so in the past).

I tried demuxing MP4/M4A to raw AAC with Yamb/MP4Box, but surprisingly that actually increased the file size a bit. Perhaps MP4 somehow packs the stream more effectively and the despite the additional MP4 container structure the overall file size can be smaller than the size of the raw stream.Could the AAC developers explain how AAC is stored in the container and how the bitrate values are saved in the "atoms"? Does the MP4 container structure have a defined size overhead that can be detected or calculated?

Raw AAC streams have frame structure just like mp3, so there is an overhead of a header for each frame.

There is an excess "the" word in my previous reply: ... and the despite the additional MP4 container structure... . The forum software doesn't allow me to edit it anymore. In my opinion the replies should be editable longer - 24 h or so.

Regarding the recently discussed, determining bitrates is not an issue. IgorC just misinterpreted the line on nao's site. To end the speculation, I have attached a set of Quicktime CVBR files at 126, 127, 128 kbit/s targets (effectively in the 141-143 kbit/s range), which should be "impossible" to produce according to Igor:

I am not speaking about QT CVBR. I am speaking about determining the bitrates in general. Obviously those programs that I mentioned read info that is stored in the MP4 headers. I am not an MP4 expert and I would like to know if that info is always correct and if I can trust some of the available tools.

You have not explained what software you use for displaying the bitrate values.

BTW, seems like you don't agree with me and C.R.Helmrich that iTunes should be used for encoding CVBR. Correct?

Oh, I forgot: Who says the number of encoding parameters needs to equal the number of data elements? Even something such as the decision whether to use short blocks or a long block already requires a handful of parameters.

Not me. What I said is that number of principal parameters of stream (and even data elements) is less than 100, and these are common for all competitors.

While samples are short, it will be a test of rate control volatility. And this isn't worth the efforts. IgorC rejected rpp3po' idea since it doesn't look real. But in "real life condition" bitres at the begining of fragment wouldn't be reset. And what is more important the bit reservoir state at the end of fragment wouldn't be irrelevant.

For "real life condition" use looped samples. Then pick fragments with lowest bit-length for each encoder. This way you could check whether CBR is that bad.

After all, rate control is not most intriguing part of AAC. Intra-frame stuff is of more interest.

BTW, seems like you don't agree with me and C.R.Helmrich that iTunes should be used for encoding CVBR. Correct?

Yes. The test's goal should be AAC at 128kbit/s respectively an encoder setting that produces 128 kbit/s on average. This is true for Quicktime TVBR at Q60 and CVBR 121. In contrast iTunes' "128 kbit/s" CVBR preset produces considerably larger files on average. What is missing now, is a matching Q value for Nero.

Edit: And don't forget, we can exactly clone iTunes' encoder by using Quicktime with CVBR --normal.

Alexander, I also supported the idea to use hand picked files, to get as close to 128 kbit/s average, at first. But I don't do anymore. Let us just use a setting for each encoder that will result in a collection average of ~128kbit/s. Some contenders like Quicktime TVBR, which is only alterable in increments of 8, don't allow fine tuning or even want to downsample at some settings. This would be a mess after all. Using one preset for each encoder really seems the most practicable approach.

Do you have any opinion about the proper way of measuring the MP4-AAC audio file bitrates? For instance, is it fine to use foobar?I have tried also Mr QuestionMan and Mediainfo, but the results are not always identical.

Bitrate from Audio stream must be taken into account in MediaInfo and not the overall bitrate from General.Bitrate in foobar is also correct.

You are still not saying what do you use for measuring the bitrates...

IMHO in a VBR listening test the encoders that can't be adjusted precisely (i.e. the encoders that have only one suitable bitrate related setting) should be measured and the measured values should be averaged. After that the encoders that can be freely adjusted should be set to produce that average value (naturally always using the same test files).

For instance:

Encoders that cannot be freely adjusted:

iTunes CVBR => x kbpsQT TVBR => y kbpsCT CBR (does it have a VBR mode?) or Divx VBR (I downloaded the demo version, but I have not tried it yet and I have no idea of how it works.) = z kbps

You are still not saying what do you use for measuring the bitrates...

Normally just he OS X file info. The OS supports this out of the box. For the 87 album test I have loaded the set into Foobar within VMware. For the three above CVBR 126, 127, and 128 files OS X reports 140, 141, and 143 kbit/s. Foobar: 141, 141, 143. Extracted to raw AAC and calculated by hand: 144.6, 145.1, 147.0.

So I think CVBR can be counted as freely adjustable.

As long as always the same tool is used to determine the bitrates in this test, everything should be ok. I would be fine with agreeing on Foobar.