x264: extreme quality on anime!

[Sirber]

Hi

Just made my first real encoding on naruto episode 143 using x264 with realanime's defaults (all the fancy stuff, 3bf, inloop +3), 3-pass ABR. I used 536kbps with a 64kbps HE-AAC soundtrack. Watching the source (170MB) and the result (100MB), I couldn't say which one is the source.

Many thanks to x264 devs!!! :D :D :D
Keept the excellent work!!!

http://www.detritus.qc.ca/files/x264/snapshot20050718211820.jpg
http://www.detritus.qc.ca/files/x264/snapshot20050718211711.jpg
http://www.detritus.qc.ca/files/x264/snapshot20050718211949.jpg

[leowai]

Nice work! I almost can't find any blocky picture here.

By the way, is these encoded with default settings in x264 with exception of inloop increased to 3?

[Japhsoncross]

i also did a lot of tests these days, and x264 is amazing in anime materials.

but i also found that x264 blurs the details in natural materials......i don't know the reason.
my settings are:
x264 --keyint 240 --min-keyint 24 --bframes 2 --b-pyramid --ref 16 --filter -3:-3 --ipratio 1.1 --pbratio 1.1 --pass 1 --stats "xx.log" --analyse all --weightb --me umh --merange 32 --subme 6 --8x8dct
x264 --keyint 240 --min-keyint 24 --bframes 2 --b-pyramid --ref 16 --filter -3:-3 --ipratio 1.1 --pbratio 1.1 --pass 2 --stats "xx.log" --analyse all --weightb --me umh --merange 32 --subme 6 --8x8dct

extreme slow settings, but the details of encoded frames don't satisfy me even if the bitrate goes higher(1.2M).

Sirber, do you have any tests on natural materials?

[dinolib]

If you use inloop -3 (instead of +3) you blur details! <= EDIT:FALSE!! It's the opposite

cheers

[Japhsoncross]

THX, i'll have a try.

----------------------
i replaced +3 with -3, it blurs more...

[Sirber]

Nice work! I almost can't find any blocky picture here.

By the way, is these encoded with default settings in x264 with exception of inloop increased to 3?+3 is default :)
If you use inloop -3 (instead of +3) you blur details!

cheersCan you post screenshots?

[Japhsoncross]

+3 is default :)
Can you post screenshots?

i compressed the three files(source, loopfilter-3, and loopfilter+3) in jpeg format at max quality.

[Sirber]

Images in pending approval. Which value do you recommend for RealAnime?

[Caroliano]

I'm having impressive results with x264 in animes too. I aim for quality and found that x264 can have a similar quality with almost two times lower bitrates. 500 ~ 600 is now the bitrate for high quality animes instead of 800 ~ 900 of Xvid.

I use the defaut adaptative in-loop filter (in others words filter=0) for VFW sharktooth's build. It leave all the details I want. I tried to play a bit with it but the defaut seems good for HQ anime.

And about the quantizers? I think that q24 is very good quality and q22 is almost perfect. I cap my quantizers and don't let the encoder down to less than q22. It would be a wast of bits for me. What you guys think?

[Sirber]

I use default quants. x264 is pretty adaptive. I get similar results with no bframes!!! :D

(from my first 400kbps comparison, which bframes were disabled by error)

[Caroliano]

But you see any quality improvement in anime content beyond q22?

And this no-bframe thing is witch this naruto episode at this bitrate? Or was in the one piece clip?

[Sirber]

But you see any quality improvement in anime content beyond q22?
I don't know. I'll try ASAP.
And this no-bframe thing is witch this naruto episode at this bitrate? Or was in the one piece clip?
One piece. Did not try on a full encode yet. I got crash (exitCode -1 at 100% encode) on my other naruto #143 test encode at 400kbps.

[Isochroma]

I don't use anything greater than q20, and I can see quality improvements at even lower quantizers. I am working with very sharp, clean hi-res DVD originals, and I have a 21" Flat Trinitron monitor. So, I can see all the details that everyone else is missing.

[Caroliano]

Hum. For me in lower quants will only represent better the noise of the source because the in-loop filter is lower...Of course, I don't have a 21" Flat Trinitron monitor and a perfect source, only a good one. And I'm not aim to SHQ encodes, only HQ...

[IgorC]

x264: extreme quality on anime!

The same I can say for Nero H.264.
These two codecs are best right now.

[Japhsoncross]

Images in pending approval. Which value do you recommend for RealAnime?

i remember a small test you'd posted here: http://forum.doom9.org/showthread.php?t=97075 , i used your source and tested myself, gave also 400kbps, the first time i forgot to use loopfilter, and the result was quite blocky, then i tested the loopfilter@-3, and the result could be quite acceptable. IMO, at exteme low bitrates the value of loopfilter can be higher, while the bitrate goes higher, the value can be lower for more details.

[Sirber]

On my tests, +3 was pretty effective (400+ kbps).

http://www.detritus.qc.ca/files/x264/snapshot20050719211830.jpg
http://www.detritus.qc.ca/files/x264/snapshot20050719214207.jpg
Millenium Actress, 720x400, x264, 930kbps

[ChronoCross]

well one of the better things about anime is there isn't much noticeable detail loss even when you try to get rid of details cause the details aren't as overtly obvious as real life action. especially with skin gradients. Anime is smooth rather than rough and it is very hard for a codec to whipe out enough of the details to be noticeable.

I don't see a point to encoding at 400kbps in AVC as of yet. it may become smaller but it won't be as good as a high bitrate encode. and even at 400kbps it doesn;t become streamable as AVC isn't at that stage. It's good for testing. Have you done any high bitrate tests and it's effect on noise?

[Japhsoncross]

well i generally test at the bitrates 400kbps, 750kbps, and 1200kbps, and the codec x264 and ND MP. til now, i find x264 is much better on anime sources at low bitrate, for higher bitrate and real life sources, ND MP gives better result on details. i wonder if it's my mistake, my command line has been posted at #3.

[Chainmax]

Sirber: OMFG, these images look amazing, and they correspond to a 0.075 bpp :eek:

Much like the gnomes in the world of Krynn, I have a Life Quest(tm). My life quest is obtaining an excellent rip out of my mercilessly crappy R4 NTSC Simpsons 1st Season DVD set. I tried numerous combinations of filters and while I solved a good many problems, moving blocks still haunt me. I moved from latest Koepi Xvid to latest Nero Recode, and my latest script:

MPEG2Source("X:\wherever\SimpTest.d2v",cpu2="ooooxx")
DeDot()
TFM(d2v="X:\wherever\SimpTest.d2v",mode=3,PP=7,mChroma=true,chroma=true,mi=50)
TDecimate(mode=1)
FixChromaBleeding()
LumaYV12(lumoff=-2,lumgain=1.0)
ColorYUV(levels="pc->tv")
Deblock()
Deen()
HQDering()
Crop(12,0,700,476,align=true)
aWarpSharp(depth=16,cm=1)
BicubicResize(640,480,0,0.5)
BlindPP(quant=0,cpu=0,cpu2="ooooxx")
LimitedSharpen()

while producing somewhat acceptable results (not sure anymore though, I'm fed up looking at the same clip for the umpteenth time), still has noticeable moving blocks in many scenes. I haven't really searched for most used settings, so I used what I could recall people said some time ago: 5 Reference frames, Max GOP size = 10xFPS, 1 B-Frame, vector range -256 to 255.75, Chroma Optimization, Psy Enhancements High. Since the source has some really horrible blocking, I used either Adaptive Deblocking @ Automatic Smooth or plain Deblocking @ strength 6. Average bitrate is ~1620 kbps and resolution is 640x480.

Now, onto the questions:

1) What is the difference between -x deblocking and +x deblocking?

2) It seemed to me that inloop (deblocking, right?) wasn't as effective at block removal than just using a deblocker on the script. I know that the definition is "prevents blocking at the encoder stage" but don't quite get it, does it mean that it just avoids blocking due to using a too low bitrate, meaning that in my case it's useless?

3) Could you guys please post your preferred settings for x264? I'd like to give it a whirl too and would like to know some good starting values.

[Japhsoncross]

1) it means the strength of the deblocking filter.
2) the filter will improving the apearance of the decoded frames. and also in the encoding stage, the filtered image is used for motion-compensated prediction, which can improve compression performance.
3) i'm still searching for a better setting for x264, which not only does well on anime sources, but on natural sources.

[Sirber]

http://www.detritus.qc.ca/files/x264/setting.jpg
I have to switch "weaker" and "stronger", since -3 is stronger than +3.

[Sirber]

I tryed 436kbps. Shapes are a little less sharp, but I save 20MB :)

[yaz]

... I have to switch "weaker" and "stronger", since -3 is stronger than +3.dunno what u mean by 'stronger' and weaker' here but ... from mencoder readme:
... parameter of deblocking filter (default: 0) ...
A positive value reduces blocking artifacts more, but will also smear details ...
For encodes that are intended to be reasonably high quality, you might want to turn it down a little bit. However, if your source material already has some blocking or noise which you would like to remove, or if it is animation, it may be a good idea to turn it up a little bit. imho, it still stands.

the bests
y

[Sirber]

From the screenshots source vs -3 vs +3, -3 seems blurier.

[akupenguin]

When comparing deblocking settings, pick a source that has detail to begin with, and compress it enough to see the difference.
http://img302.imageshack.us/img302/5704/loopsrcyr7.pnghttp://img175.imageshack.us/img175/2940/loop6aw3.png
http://img49.imageshack.us/img49/6116/loop0by4.pnghttp://img105.imageshack.us/img105/9900/loop6ua9.png

[Chainmax]

Wow, deblock -6 looks awful. Deblock +6 blurs a lot, but that's probably what I need in my case. Too late for change though, I'm already making an encode with the following settings:

x264 --pass 1 --bitrate 1620 --keyint 240 --min-keyint 24 --bframes 3 --b-pyramid --ref 8 --filter -6:-6 --analyse all --weightb --me umh --merange 16 --subme 5 --8x8dct -o NUL x264Try.avs
x264 --pass 2 --bitrate 1620 --keyint 240 --min-keyint 24 --bframes 3 --b-pyramid --ref 8 --filter -6:-6 --analyse all --weightb --me umh --merange 16 --subme 5 --8x8dct -o Pruebax264.mp4 x264Try.avs

I will try with --filter 6:6 later. One thing: bond posted a complete list of x264 switches a while ago, and in that list the max value for subme was said to be 5. Japhsoncross, however, used 6. Which is the actual max value?

[Isochroma]

Athlon64 for H264!

Yes, anime is very beautiful compressed with this codec! It has been a miracle for me, x264 in particular.

[ChronoReverse]

Heh, yeah, I'm finding anime sources to be nicely compressed with H.264



It's rather unfortunate that the big H.264 release of the weekend (FMP:TSR) was using a poor raw and had artifacts.

It was rather reminiscent of when XviD was starting to be used how people were going "What codec do I have to use?"

I can't believe how many people are still downloading the June 2002 FFDShow from the Sourceforge site and then thinking that it sucks because it doesn't work.



If we move on to AVC+HE-AAC+MP4 (using MP4 softsubs) it'll be great :P

[Chainmax]

Oy, the settings I'm using resulted in a ~0.5fps second pass :scared:.
I tried the script I posted without Deen or Deblock and the results were about on par with Nero. I'll try including Deblock() and --filter 3:3.
In any case, what should I change in the settings I used for a speed boost with the lowest impact on quality?

[Caroliano]

@ChronoReverse: But the decode speed is bad. This is for me the worst thing about x264...

Once I can decode a Naruto opening in realtime and full resolution with my Celeron 1.7MHz I will aproval a move to H.264...

The same opening in Xvid with Qpel and GMC @3000kbps takes 50% ~ 60% in my processor.

PS: I use the latest FFDShow to decode both.

[lordreign]

Hey sirber I'm just curious, this is abit off topic, but that naruto is it your own recorded source or is it a raw or something? (dattabayo release is only 111meg not the 170 your source is) Because I'd love to reencode naruto to x264 but I can only get either dattabayo's releases or the raw (which isnt much use cause me no understand japanese :confused:) so I was wondering how u got the subs on yours if its not a subbed release (external sub file perhaps)?

Cheers.

[Ishan]

I usualy set deblocking to 0 because for me it always hurt quality (I'm only doing encode @ full DVD res @ 2mbps) If someone would be kind enough to explain how it works it'll be easier to setup. thx :)

[ChronoReverse]

@ChronoReverse: But the decode speed is bad. This is for me the worst thing about x264...

Once I can decode a Naruto opening in realtime and full resolution with my Celeron 1.7MHz I will aproval a move to H.264...

The same opening in Xvid with Qpel and GMC @3000kbps takes 50% ~ 60% in my processor.

PS: I use the latest FFDShow to decode both.



Yeah, I do understand about that.

Afterall, a 1.7GHz Celeron is like worse than a 800Mhz Pentium 3 (judging by the fact that a similarly clocked Pentium 4 is worse than a Pentium 3 1.0GHz Tualatin).

Still, I've heard reports of people playing back the FMP:TSR encode with 866MHz cpus so it's not too bad (640x352).

[Doom9]

--ref 8 --filterYou're going overboard here...
--merange 16 --subme 5Those are default values and thus not needed. MeGUI would give you a commandline without those ;)
And a fast first pass speeds up things considerably without noticable quality loss.

[Sirber]

Hey sirber I'm just curious, this is abit off topic, but that naruto is it your own recorded source or is it a raw or something? (dattabayo release is only 111meg not the 170 your source is) Because I'd love to reencode naruto to x264 but I can only get either dattabayo's releases or the raw (which isnt much use cause me no understand japanese :confused:) so I was wondering how u got the subs on yours if its not a subbed release (external sub file perhaps)?

Cheers.In respect with rule 6, I will only say they are not raw and they are 170MB.

[Chainmax]

Doom9: yeah, I didn't notice the defaults for merange and subme (is 5 the maximum for subme or is it 6?). I lowered bframes to 1 and ref to 5 but I'll keep filter 3:3 because the source is really awful. I'll report what speed gains (if any) I get. Also, what switch enables fast first pass?

[unmei]

I usualy set deblocking to 0 because for me it always hurt quality
Partially agreed. First i think to diable the inloop filter you need to actually uncheck it. The "0" here only means "use default" - and the positive/negative numers are "use more/less than default". Well correct me if necessary, i can't even look at the config dialog right now..
Now, i too think stronger deblocking is not partially nice to look at, i never increased it so far. BUT i have some DVDs that have pretty poor quality (the usual filed blending stuff a bit strong and other dirt) - there x264 fails to excel. In a few cases i was unable to filter it in a way to make x264 behave "normal", so i went for a XviD encode for a start. While i totally agree that x264 usually rocks for anime, it has some real problems with lots of stuff that should not be there - the noise/grain like in cowboy bebop is in my experience less of a problem, but field blending and ringing/macroblocks from the mpeg-2 can generate ugly persistent blocks.

[Doom9]

(is 5 the maximum for subme or is it 6?).it's 6, 6 enables RDO. You'd knew that if you were using MeGUI (why aren't you btw.. it really simplifies your life and the two, three issues that are still open are not a showstopper for anyone)

Also, what switch enables fast first pass?It's called Turbo in MeGUI ;) If you enable commandline preview, you'll see what it does (it does a bunch of things, lowering subme, limiting the number of references, limits macroblock options, motion estimation and I think that's it. It's definitely easier to have one checkbox to do that all for you instead of having to remember it.

[Chainmax]

Ok, ok, I'll use MeGUI, just don't hurt me :p.

[Ishan]

what's the default deblocking x264 use? because I find those perfect for me, I just don't set deblocking :)

[Revgen]

@ChronoReverse: But the decode speed is bad. This is for me the worst thing about x264...

Once I can decode a Naruto opening in realtime and full resolution with my Celeron 1.7MHz I will aproval a move to H.264...


How expensive are computers in Brazil?

There are a lot better processors out there that should be fairly inexpensive to upgrade, unless the prices are different over there.

[Caroliano]

what's the default deblocking x264 use? because I find those perfect for me, I just don't set deblocking :)
Hum... how you expect I answer it...

The defaut is 0 (the range is -6 to +6). The deblocking strength is adaptative. For high quantizers, high deblock strength. For less than q15, no debloking is made. I agree with you, the defaut is perfect to me :)

-> A question that poped in my mind now. If I set the debloking strenght to +6 it will deblock in q14 for example?

[Caroliano]

How expensive are computers in Brazil?

There are a lot better processors out there that should be fairly inexpensive to upgrade, unless the prices are different over there.
Well, to make a good upgrade of processors you almost aways need to upgrade the motherboard too. But that's not the point...

The computers here isnt much more expansive here than USA computers in absolute values. The problem is to get the money to paid a upgrade every year. My family earns less than 1.200 dolars per month, and is in high middle class for brazilians standarts. We can buy a month food for less than 70 dolars but a basic computer (sempron 2200) is more than 500 dolars. It is too much for us, but probabily not for you. I don't know if you understand my point. We have less money here than you there.

PS: You posted while I was writing the last mensage... and I write too slow in english...

[ChronoReverse]

No I understand just fine. After all, I only recently moved to a AthlonXP 2500+ (Sempron 2500+ basically) from a 1.0GHz Celeron (a Tualatin one so ironically it'd be faster than your 1.7GHz Celeron). I would love to have a sparkling Athlon64 system, but I'll make do with what I can get.

I'm not trying accuse you of anything, but rather just pointing out how a Celeron is a poor choice (unfortunately).

You would've ended up with faster system at around the same (or lower) price going the Duron (Applebred) 1.6GHz route =/



In any case, enough of this diversion from the topic.

I have to figure out why this DVD encode I did ended up blue (using megui and mencoder to encode AVC).

[Sirber]

x264 encoding with a 1800+ (at work) at 720x400, IT + C3D, gives a big 2 FPS :( Looking for DualCore...

[Caroliano]

@ChronoReverse: I was not talking to you... i was answering to Revgen ... but all right. This celeron 1.7 is not a so bad choice. It is faster than your old Celeron 1.0 MHz, the diference of clock rendiment is not that big. Intel never launched a P4 slower than a existent P3. They jump from PIII 1GHz to P4 1.4GH instead.
It is a fairly good processor of intel. It is cheaper and don't heat too much, but I agree, an AMD would be better.

A bit more in topic: I don't have problems with 640x352 clips. Only Last Exile was a bit tricky but wachable... the problem is 640x480.

@Siber: Well come to my world :p

[Sirber]

Better get a P4 or AMD64 for x264, or else you may cry :)

[ChronoReverse]

@Caroliano

Ah the tragedy of clock speeds.

Unfortunately, even a 1.4GHz Pentium 4 is "slower" than a 1.0GHz Pentium 3. I am not referring to MHz but how "fast" they actually do work.

That is, you can encode faster with a 1.0GHz Pentium (tualatin) than with a 1.4GHz Pentium 4 (williamette). That's right, your fps will be higher.

[Caroliano]

ChronoReverse: I think that is better continue this discussion in private mensages... we are off topic...

[Sirber]

Just watched One Piece 152 in x264 @ 436kbps. I just can't believe it!!!! :D :D

[treehh]

Hiyall, I'm ripping the most popular tv cartoons S@@psons using FairUse1.2. But after reading all the good things here about RealAnime3.0.0 and x264. I want to give it a try. Cuz the Xvid result file doesn't run well on BSPlayer.

So my question here is
1) is x264 a codec/library? If so, which GUI should I use?
2) What is the typical settings for x264?

[Sirber]

1) both
1a) RealAnime, MeGUI or virtualdub
2) for anime realanime's defaults are pretty cool. gives ~85MB per file.

[Joe Fenton]

Just watched One Piece 152 in x264 @ 436kbps. I just can't believe it!!!! :D :D

Yeah, x264 (h.264 in general) is FANTASTIC for people wanting to make backups of their anime collection for playing on a home network. You can put twice as many episodes in your library with no loss in quality. Instead of flipping through racks of DVDs, I just throw them in the closet and just play an x264 encode off a harddrive.

The only negative at the moment (and it's not THAT negative) is the encoding speed... which is actually not that bad for me since I have a dual-opteron I use. :D

[ChronoCross]

while on the topic of encoding speeds. Are there any bitstream side effects to using more than one thread? I don't remember where I read it but there was a problem with the GOP when using more than 1 thread?

[Sharktooth]

Yes, there are some side effects since the frame is sliced in 2 or more parts (depending on the number of threads).
But with 2 threads the difference is usually about 0.01db...

[amango]

The first time I used x264 I was amazed about the decreasing file size I got against other codecs. But...

In my opinion x264 smooths too much (default settings). I used XVID the most time before. I always use 1 Pass-Quantizer encoding to save time. Size is not a matter for me. I really don't know what settings I should change to enhance the quality in anime. With normal settings and Quantizer 20-22 some details looks to smoothed and the picture quality and sharpness decreases.

[Sirber]

I never tryed 1-pass CQ with x264, since it kick too much a*s in ABR 3-pass.

Since size doesn't matter, why do you use x264? Why do you recompress at all?

[Caroliano]

In my opinion x264 smooths too much (default settings)
These defauts are from RealAnime or from official CLI/VFW interface? Because RealAnime seems to use +3 as defaut debloking, but the official defaut is 0. This may expain the exagerated smooth. Then set it to 0.

If not then you can try to lower the in-loop filter (deblocking) to -1 but I don't recomend this, especialy for animes. I think that that way you is only preserving more ringing and other compresion artfacts... At q22 and debloking 0 the detail preservation is fine IMHO.

[Sirber]

These defauts are from RealAnime or from official CLI/VFW interface? Because RealAnime seems to use +3 as defaut debloking, but the official defaut is 0. This may expain the exagerated smooth. Then set it to 0.

If not then you can try to lower the in-loop filter (deblocking) to -1 but I don't recomend this, especialy for animes. I think that that way you is only preserving more ringing and other compresion artfacts... At q22 and debloking 0 the detail preservation is fine IMHO.Realanime new defaults are +1 now. If you installed the final 3.0 over an old RC, the defaults didn't update. Do do so, delete all files in "/profiles/" and reload realanime.

[Caroliano]

I didn't tried the final version yet... thanks for the information.

[DarkZell666]

Hi Sirber, Hi everyone !

I just stumbled across this thread about animes, and this is what I use x264 for ! To reencode those bl**dy 220MB episodes to fit 50 of them on a single DVD !

Great news that 3pass ABR < 500kbps rocks, I'll try on some very clean HxH OVAs that I have (can't find any cleaner source than those lol). Though I don't understand something : what does 3pass do better than 2pass ?
Don't tell me that a simple bitrate reallocation can lead to such quality ? oO

Other very important question : do you resize the picture to 512*384 or is it plain 640*480 ? (sorry I don't use realanime yet I'm still using vdub + x264vfw ^_^) using 512*384 I managed to sqeeze episodes down to 100MB (90MB video + 10MB HE-AAC 64kbps audio ^^) using 2pass ABR.

*bouncing up and down oO*

[Sirber]

1) Well, it's better ;)

2) I keep 640x480 and it scores 85MB (436kbps x264 3-pass, 5 ref, inloop +1, 3 bframes, all the fancy stuff; 64kbps HE-AAC audio). On clean source (One Piece), I can't see a difference, but on medium source (Naruto), it x264 keeps the artefacts of xvid :D

[Synergy37]

What program is all this being done through?

[Sirber]

Well, you can use RealAnime or any other soft that support x264: MeGUI, AutoAC, VDub, etc.

[Chainmax]

Sirber, why not trying Vorbis aoTuVb4 instead of AAC? Recent 80kbps listening tests show made at Hydrogenaudio showed that Vorbis aoTuVb4 @ 80kbps sounds way better than any other codec. I'd assume the difference is even bigger at 64kbps.

[ChronoCross]

Sirber, why not trying Vorbis aoTuVb4 instead of AAC? Recent 80kbps listening tests show made at Hydrogenaudio showed that Vorbis aoTuVb4 @ 80kbps sounds way better than any other codec. I'd assume the difference is even bigger at 64kbps.

isn't it about mp4 compatibility? It's better to use aac in mp4.

[Caroliano]

isn't it about mp4 compatibility? It's better to use aac in mp4.
He uses Matroska... So no hurt in compatibility. I'd say a boost. I would like use vorbis.

And the nero encoder isn't as good as other HE-AAC encoders:

http://foobar2000.net/divers/tests/2005.09/AACHE/01/plots.png

Source: HE-AAC v.1 & v.2 comparison, Winamp vs Helix vs Nero Digital (http://www.hydrogenaudio.org/forums/index.php?showtopic=36868)

[Sirber]

Wierd... Everybody tells me nero codecs are better than helix ones :confused:

Also, I use MKV (3.0) and I will use MKV in RealAnime LE too.

About vorbis, well, why? In next realanime version, I aim bellow 64kbps, like 48 and 32 with parametric stereo :D.

[Caroliano]

Yeh. The only advantage Nero has currentily is that it has the ability to code 5.1 audio when the other implementations are stick in 2ch. But Nero developers will launch soon a new version of their audio codecs. The actual is from the end of 2003, so its very out-dated.

guruboolez also was surprised:
Was it really obvious that CT implementation should be considered as better than Nero? On this board, I can't remember anyone making such test or even such assumption. Remember Sebastian Mares and his project to organize a collective listening test at 64 kbps: he considered Nero Digital and the upcoming Apple's implementation as the two most interesting ones. Most people on this board (including me) were convinced that Nero Digital is a better encoding solution (compared to CT).

[DarkZell666]

Well well well ...

is 230kbps correct ? well ... of course !! :D

I've just tried encoding naruto 131 @ 230kbps (512*384 res)
using 3pass just as Sirber suggested : it's absofactolutely INSANE o_O

that gives me 37MB video and 9MB of audio (using vorbis -q0 @ 32khz).

I encountered a wierd flaw though : at the beginning of the episode, some frames don't play (ie: the movies jumps dozens of frames, freezes and waits for the sound to catch up, and plays correctly up to the end). I guess there are 1 or 2 keyframe(s) missing at the beginning or something stupid like that ...

Note : I used the High Profile features (ie : 8x8DCT and 8x8 IntraSearch) for encoding with x264, and Nero Video Decoder filter for decoding.
I'll try with ffdshow later on. I'm encoding a MainProfile version (no 8x8DCT etc.) just to be sure. I'll post further comments about this later. (dunno if vdubmod's mkv output, haali's matroska splitter, or x264 are the cause here or what ...)

Anyway, I knew x264 was amazing, but to such extent ... wow O_O
I'll get rooting though the CLI options to get more out of it :P

[Sirber]

wasn't the minimum of Vorbis 64kbps?

[akupenguin]

Say what? Vorbis is quality-based VBR. If you encode silence you'll get 0 kbps at any settings, and a movie soundtrack at q0 can easily go below 64.

[mezzanine]

Yeh. The only advantage Nero has currentily is that it has the ability to code 5.1 audio when the other implementations are stick in 2ch. But Nero developers will launch soon a new version of their audio codecs. The actual is from the end of 2003, so its very out-dated.

guruboolez also was surprised:

FAAC encoder can do 5.1 channel audio.

[Sirber]

5.1 He-aac?

[mezzanine]

5.1 He-aac?

No. AAC-LC

[DarkZell666]

btw Sirber I think you got mixed up (please forgive me if you didn't ^^) : khz and kbps aren't the same unit at all :)

32khz is the sampling rate (not the bitrate : kbps), and @ 32khz, q0 gives me something like 53kbps (< 64 hehe).

If I used the original samplerate (44,1khz) q0 would have given me rather ~64-72kbps.

[Sirber]

oh, sorry. I read "kbps" lol. My bad :D

[Caroliano]

wasn't the minimum of Vorbis 64kbps?
No. The minimum bitrate of Vorbis currently is around 10kbps @ 8KHz. In 48KHz vorbis can reach only at 32kbps using q-2. I'm using AoTuV b4 encoder but I think that the official 1.1.1 can do that as well.

Realy the minimum of Vorbis was 64kbps, but a long time ago, back in the 1.0 I think.

[Sirber]

Some years ago when I was using vorbis, Q0 = 64kbps and Q-1 = ~56kbps. Never heard of -2 :( Could you point me to a webpage with those specs? Thanks!

[Shinigami-Sama]

mmmm
AVC anime
I realy gatta get upto date,
any good place to start for intermediate h264 stuff?
I only have an hour or so free to play around here now a days :(
I'd love to make a few backups of some of my shiny dvds like mononoke hime
which is still in its plastic o_O

[DarkZell666]

About parametric stereo btw, I've just tried encoding
some rich trance songs of mine which have high output in all frequency bands : standard HE-AAC @ 48kbps sounds cleaner than PS-AAC @ 48kbps ...

PS-AAC sounds "robotic". And I can confirm that nero's HE-AAC does sound really bad compared to helix's and AAC+v2 (not FAAC in any case, FAAC doesn't seem to do any better than standard MP3 @ 64kbps lol).

Whatever, the current implementation of PS-AAC that I tried didn't sound that good at all (as I said, HE-AAC @ 48kbps was cleaner than PS-AAC).

Well, sorry if this was off topic, (I guess it is) but it was worth mentionning considering the previous chart posted by Caroliano.

Cheers, and long live h264/x264 :D

[Caroliano]

Specs? I can point you to vorbis official page (www.vorbis.com) which have the version 1.1.1 (that I think suport q-2) and for the topic about aoTuV b4 (http://www.hydrogenaudio.org/forums/index.php?showtopic=34915) in HA, which also have a link to Aoyumi's page. Is it enough?

I used OggdropXPd (http://www.rarewares.org/ogg.html) to make my encodes. I prefer 32kbps@32KHz, it sounds smother for me.

[Sirber]

aoTuV Beta4 [beta3 >> beta4]
# An addition and change of the code of a channel coupling processing portion. Thereby, disorder of the sound energy on hearing becomes small. And a part of additional code of beta3 which is not required has already been deleted now.
# Tuning of Masking relation and Noise Normalization. These mainly influence balance and the quantity of distortion which can be heard.
# The bit allocation by the low bit rate was devised. This is generally effective.
# Bug fix of beta3Not much "specs" :( What's the minimum bitrate at 44khz?

[Caroliano]

Ah. That kind of specs.

You can look at source code of OggdropXPd since it change perfectly the data acording to setings. As I don't know programing, I only set the -q and sample rate and see what it shows as the expected bitrate.

Warning: you must go out of the 'encoding options' window when change the sample rate because it don't update the bitrate values until then.

[Sirber]

-q -2 = ~32kbps

Maybe not the best place to ask, but could I use aoTuV with besweet? I'm thinking to use vorbis instead of nero he-aac in RealAnime LE.

[Caroliano]

I use Belight as GUI for Besweet. I changed the libvorbis.dll in the folder and all went well. So I guess yes. Maybe in audio forum you can get more informations.

And I don't know if vorbis is realy better than HE-AAC at these bitrates (<=64kbps) because I don't done a listening test yet and the listening tests in these bitrates are pretty old.

[Sirber]

I did one and vorbis scared me at 32kbps. So metallic, sounds almost mono on my 5.1 speaker set.

[Caroliano]

I done one also now. I agree with you that HE-AAC out performs vorbis by far at 32kbps @ 44.1KHz. I made a 32kbps @ 32KHz sample also and it sounded less metalic, better for me but far of HE-AAC yet. Not cientific or blinded comparision, only a informal and personal one.

I will try 64kbps also. Probabily vorbis will perform better than this time, but I don't know if better than HE-AAC. Let's see (or hear, your choice). :)

[Sirber]

go ahead, while we are at it :)

[Caroliano]

Well, I had trouble finding the apropriaded bitrate for nero. Streaming was 1.05MB and Normal was 2.37MB and Vorbis was 1.47MB. I will sleep now because It's late and I need to wake early tomorrow. I listened a bit to them and vorbis seens somewath better than the biggest HE-AAC... strange... I need to sleep. Tomorrow I make real tests...

[Sirber]

lol, good night.

@mod, could you split all the audio thing in a new thread? thanks!

[Caroliano]

Now I done more acurated testing. HE-AAC has some disturbing artfacts around the percursion instruments, more disturbing than the bost that vorbis give to them. But the voice was slight better coded by HE-AAC , vorbis still a bit metalic. Considering that voice is more important for video coding it was a tie between diferent bitrates. So, vorbis advantage.

I made another test, but that time with a anime soundtrack in 128kbps MP3 (in other words: transcoding). Vorbis was totaly transparent to my ears at ~58kbps (it undersized). HE-AAC had some artfacts in a laugh and generaly the "volume" was kinda higher... And HE-AAC was in a bitrate far higher than Vorbis again. It must be what guruboolez called "SBR artfacts".

And I say again: this is not an cientific or blinded comparision, only a informal and personal one. I don't have trained ears and don't even know how name the artfacts I heard. I can host this last test in any place if someone want. 23 secs per sample, less than 1mb in total.

[Sirber]

So, if I plan to use between 32kbps and 64kbps, I better stick with HE-AAC?

[Caroliano]

If you prefer bitrates closer to 32kbps HE-AAC > Vorbis. But vorbis improve faster as you high the bitrate and at 64 it is already better than HE-AAC. In the 2nd sample I tested it reached at transparency at 58kbps, for me. HE-AAC aparently never reach transparency. So is hard to say what is better, even for me. I will make 48kbps tests... ;)

Do you too.

[Sirber]

I will make some tests when I get free time, my cat poohed again in my bath :devil:

[DarkZell666]

Well, I've tested HE and PS AAS both this morning @ 16, 24, 32, and 48kbps, but this time, encoding from a commercial CD (not reencoding an MP3, which causes so much more artifacts, omg oO) :

HE and PS-AAC @ 48kbps hardly stands out from original CD, and @ 32kbps it sounds like MP3@128kbps ... in fact the "robotic" artifacts from PS-AAC didn't appear this time, and I guess they were caused by the "lossy->lossy : MP3->AAC" conversion :)

Listening very carefully, I could hardly distinguish PS-AAC and HE-AAC @ 32 and 48kbps, but PS sounds cleaner @ 24 and slightly cleaner @ 16. I am REALLY astonished by the quality achieved at so low bitrates ... O_O

500~900KB for a 4:30 song ... O_O near-cd quality ? well well well ... what else to say lol : in fact the stereo panning does lose a bit of quality but it's just about the same loss as MP3 @ 128kbps so I won't complain :D

And when I say HE and PS-AAC : I'm using AAC+v2 of course, but helix's HE-AAC shouldn't be far behind =)

[Raziel6969]

Hello,

Here there is a link, to audio discussion at low bitrates:
forum.doom9.org/showthread.php?t=99643&page=1&pp=20 (http://forum.doom9.org/showthread.php?t=99643&page=1&pp=20)
Maybe this info can be usefull! :)
Note1: I made some quick test with 1 song from orginal CD (not lossy -> lossy converssion) to AAC-HE 64kbps and AAC+V2 48kbps, and I can tell what is what all the time (AAC+V2 lose some stereo than AAC-HE, but is the better sound you can get at very low bitrate!)
Note2: I'm just a normal audio listener, i don't have 'golden ears' like the people at H.A.

Bye

[Sirber]

cool! Maybe I will add both codec to RealAnime LE...