RealAnime 5 - Feature Request and Development Thread

[killerhex]

so no encode all audio option :mad:

[Sirber]

IMO japanese track and english subs is enough. Dub sucks most of the time, so adding both is just a loss of space.

[Deinorius]

I support MKV as input, not output.
So, for each file, I will start SubRip and wait that you convert them, then encode? You wait a longer time for the encode. Running through a Vobsub File goes much faster.

[Sirber]

You wait a longer time for the encode. Running through a Vobsub File goes much faster.I don't quite understand :confused:

[Deinorius]

Encoding a video needs for example an hour. Converting a Vobsub File into .srt needs just a few minutes. That's my point.

[anne_so78]

I've done some testing of the new HE-AAC v2 codecs from Ahead and Coding Technologies'. Here are my impressions for 32kbit encodings:
Coding Technologies' aacPlusv2 v7.2.0.a contains a few improvements in certain aspect of the sound. Overall it is better than the previous version, though only by a small difference.
Ahead's new and free (seriously, what's the catch!?) MPEG4 audio codec is a big improvement over the previous version. The warbling effect apparent in dialogue is gone. Music sounds great with this codec. However, the voice quality, while much better than before, is not up to the level of the CT's encoder. High's sound harsh and fatiguing and dialogue isn't as clear and smooth as CT's encoder.
Since the newer Ahead codec, the difference between the two encoders (Ahead and CT) isn't very much and one can hardly differentiate them through cheap desktop/laptop speakers. Still, the difference exists, especially when listening through headphones...
So, for movie/cartoon encoding @ 32 kbps, CT's encoder reigns supreme...
[Samples can be downloaded here (http://www.mytempdir.com/673158); CT's sample was made using the old encoder]

I've checked to see if encoding with Ahead's encoder introduces any delay or not. Watching the encoded video's, I couldn't easily detect any delay and any such perceptions could have been imaginary. Anyways I decided to analyze the audio with a graph (using Audacity v1.3b) and Lo and Behold! Delay!
http://img376.imageshack.us/img376/4030/delay6qw.png
I extracted a wavefile and converted it to CT's aacPlusv2 32kbps using BeLight, and also converted the wavefile to Ahead's (latest) HE-AACv2 32kbps. Afterwards I converted both MPEG4's to wave using Winamp's Diskwriter output plugin. The first two bars are the source wavefile, the second two are Ahead's encoder, the third two are CT's. As you can see CT's wavefile has the longest delay (the delay in this sample, according to Audacity, is 151ms). I thought Ahead's encoder would pass off delay free, but not! Although, it is a small delay which I may or not have noticed during playback. Hmmm, why is it so difficult to get perfectly synchronized streams?...

So, keep that delay checkbox a little while longer:sly:

[Sirber]

Cool comparison! :D

Can you make it for Nero for 24kbps, 32kbps and 48kbps? I'll hardcode the values of the delay. I did not notice any delay with AAC LC (nero).

[anne_so78]

Believe it or not, even mp3 adds delay to the stream, but only about 25ms. I'll check out the rest of the bitrates tomorrow. I hope there'll be some kind of consistency...

[Sirber]

So, if my source is MP3, and I encode to AAC HE+PS, I'll get a kick ass delay? :(

[killerhex]

is the delay good or bad never understood

[Sirber]

the delay makes the audio and video not playing at the same time, so it's evil.

I got to encode video (x264) with RealAnime 5. Now, I'm at audio and final merge. Preview 1 will only handle AVI files.

I removed Theora. No one uses it anyway.

[killerhex]

any support for files encoded in AC3 5.1

[Sirber]

5.1 files are too big (filesize) and I personaly have nothing to playback them (2.1 on PC and 2.0 on TV). Same as RA4, input audio will be downsampled to 2 channels while keeping surround data.

Good thing (unrelated with 5.1), RealAnime 5 accept every audio codec now, as long as they decode via DirectShow or NicAudio.

[killerhex]

anything else until release

[Sirber]

work? ;)

Best make the specs before it's released no?

[Inventive Software]

What about Aud-X support?

[Sirber]

well, not exactly a 2 channel codec, nor a low bitrate one ain't it? ;)

[anne_so78]

Sirber, I am using Graphedit (+ WavDest and Filewriter Directshow filters) to extract a wavefile from actual playback through Haali Media Splitter and ffdshow. Then, I analyze this wavefile through Audacity to find the exact delay introduced into the audio stream. I am hoping this method is faultless.
However, I did find something peculiar: An audio/video file with 32kbit CT's aacPlus v2 compiled manually by me by first extracting a wavefile from the source through VirtualDub, then encoding in BeLight and finally muxing in mkvmerge is different from the same source encoded in RealAnime 4 RC3 (a difference of 8ms)
Besides the delay introduced by the CT aacPlus encoder itself, how did RealAnime add an additional +8ms of delay?

[anne_so78]

Got it! It's the 48khz>44.1khz downsampling that introduces the +8ms delay...

[Sirber]

hum... what do you recommend? :confused:
I'll only use Nero commandline with RealAnime 5

[anne_so78]

Use CT's encoder after I give you the delay value's for various bitrates. Don't discard the best. Or keep both...

[Sirber]

Why not using Nero? It got 2 pass :) Also the delay is less in your test.
it's also legit to use

[anne_so78]

Here are the delay values detected (for bitrates of 24, 32 and 48; Nero 2-pass ABR encoding has also been seen following the same delay patterns) using the method described in post#68.

CT = Coding Technologies' aacPlusv2 encoder found in RealAnime4 RC3 Package
Nero = Nero HE-AACv2 encoder, May 1st 2006 version

Nero encoder must be specifically instructed to encode with parametric stereo at 48kbit bitrate; otherwise it encodes with only SBR resulting in inferior quality. Also note, the following delay values are valid only for SBR+PS encoding.

============================================

For sources with 48khz samplerate:
CT: +107ms
Nero: +75ms

For sources with 44.1khz samplerate:
CT: +116
Nero: +82

============================================

[killerhex]

how long does it take to hardcode the sub into the video stream

[Deinorius]

How long does it take to encode a video stream with XviD or x264?

That's the answer. :D

[Kayser]

anne_so78, those delays are the same for every file? :thanks:

[Sirber]

If yes, I will hardcode them but let the user change them (i.e. correcting the hardcoded value), ex:

User: 0ms + PS: +75ms = +75ms delay
User: -50ms + PS: +75ms = +25ms delay

[edit]

Does the delay change if you use another bitrate?

[anne_so78]

anne_so78, those delays are the same for every file? :thanks:
Yes. I've tested with more than one sample, and the delay patterns were found to be consistent.

Does the delay change if you use another bitrate?
I've tested bitrates of 24, 32, and 48. No change. Except Nero@48, but that's because Nero switches to HE-AACv1 encoding at that bitrate. Just instruct Nero to encode to HE-AACv2 at 48 kbit, then the given delay-values are valid again.

Nero@48kbit with default settings is really bad, I actually like 32kbit better than 48kbit. I wonder why Ivan allows his encoder to encode in this way:confused:

Sirber, could you please include CT's encoder also (like a checkbox "Use CT encoder") ? About the legit stuff> many aspects in your program are on shaky legal ground (x264, mp4box etc.), what are you gonna do about them;) ? Screw the law!:devil:

To be honest, @24kbit and @48kbit(with PS of course) Nero has better quality than CT(tested with the old encoder); Neat stuff! It's only @32kbit, that the CT encoder has the edge... So retain the encoder a little while longer, it couldn't hurt...

[Sirber]

I've tested bitrates of 24, 32, and 48. No change. Except Nero@48, but that's because Nero switches to HE-AACv1 encoding at that bitrate. Just instruct Nero to encode to HE-AACv2 at 48 kbit, then the given delay-values are valid again.

Nero@48kbit with default settings is really bad, I actually like 32kbit better than 48kbit. I wonder why Ivan allows his encoder to encode in this way:confused: I force AAC HE+PS for my "PC" bitrates and LC for iPod.
Sirber, could you please include CT's encoder also (like a checkbox "Use CT encoder") ? About the legit stuff> many aspects in your program are on shaky legal ground (x264, mp4box etc.), what are you gonna about them;) ? Screw the law!:devil:

To be honest, @24kbit and @48kbit(with PS of course) Nero has better quality than CT(tested with the old encoder); Neat stuff! It's only @32kbit, that the CT encoder has the edge... So retain the encoder a little while longer, it couldn't hurt...I hate "exceptions", but since RA5 moto is KISS (http://acronyms.tfd.com/kiss), it's very easy to change the code to use CT instead.

[Sirber]

Many Thanks for your testing! Your help is very appreciated! http://www.detritus.qc.ca/images/jap.gif

First preview release of RA5 will surely be released in 2 months, since tomorrow leave rainy Canada and leave for one month in Australia :D

ja neh! :D

[anne_so78]

Bon Voyage!

[Sirber]

I might have to use CT instead. Nero doesn't like my WAV files...

http://forum.doom9.org/showthread.php?p=829631#post829631

[Sirber]

Works #1 with CT. When playbacking in FFDShow, I have a "Jitter" of -42ms. IS it automatic delay correction?

[Sirber]

Allright guys, the first working file encoded with RA5:

http://multiterra.mooload.com/file.php?file=files/190506/1148059994/E001.mp4

using CT encoder, no delay fix yet nor audio normalization.

[modsoul]

i have request (if its not too much trouble.)
would it be possible to add a support for saving our own selected options... in a profile like thing. i mean your defaults are great but i sometimes i like to have a little more control over the encoding.

i did search the thread for "profile" but still sorry if this has beenm asked

lastly thanks for this great program. before this i had compress all my anime using a python script for mencoder but this reall made it easy.

[anne_so78]

Sirber, I know you want to keep everything as simple as possible to make the program easy to use, but why not create a 'basic' mode and an 'advanced' mode where every option under the sun can be tweaked. Then comes the name change, and the relaxing+sipping_iced_tea part;)

[ggab]

Allright guys, the first working file encoded with RA5:

http://multiterra.mooload.com/file.php?file=files/190506/1148059994/E001.mp4

using CT encoder, no delay fix yet nor audio normalization.
Not Found

The requested URL /file.php was not found on this server.
Apache/2.0.52 (CentOS) Server at multiterra.mooload.com Port 80



PS: i will miss MKV output support.....

[clone83]

SIRBER PLEASE DO NOT REMOVE MKV OUTPUT!!!! mkv is more up-to-date then mp4 and ogm.

[anne_so78]

guys, what advantage is there for MKV over MP4 ?

[Eretria-chan]

Sheesh, I'm away for a week and all this crap happens? :confused:
*) Don't remove mkv output! Mkv is the best container, period. If you remove it I'll simply have to re-mux the streams in a mkv container, which means a lot of more works and your version becomes a downgrade than the previous version.
*) Hard subs? Not that it's bad, but still... if the container supports it, like they do, then I believe subs in the container are the way to go.
*) And remove all that crap from the download! Don't know how many times I've actually complained about that... keep the file size down! If all those things are necessary, then make the installer look for those installed components, and if not installed, then ask the user to install them by pointing a link or make the installer download them.

Dammit... are you going to make RA 5.X to RA 1.X? :scared:

[LAIN]

I'v talked with Sirber concerning the MKV output. We agree to only have MP4 output. The main reason that we decided to remove it it that we need a version of realanime more simple that support principally ipod output. another reason that mp4 is a "standard" output that can be played on almost every os.

If you really want to have mkv output, i strongly suggest you to use the version 4.1.2 of realanime that is stable. We will continu to update the binaries of x264 and all the componant that can be updated. For now there is no develloppement on version 4.1.2 scheduled until a major bug is discovered or if there is some features that can be added or modified.

for all the componant that currently is used by RealAnime (v 4.x) they are necessary and we want to allow the user to have the full package so that a network installation is possible. We might do a simple version that need to download/update componants, but, like I said, there is no schedules made for this right now. we currently put all our time on the developement of RA5.

Since Sirber is out of the country for ~4 weeks, the developement of RA5 will be slowed during this time.

[Eretria-chan]

This is truly outrageous. Then I must toss away RA5 and look for an alternative, because RA4 just doesn't cut it with all those besweet errors and halting on errors.

Shame on you, Sirber. Your program will be dubbed Crap Anime 5.0 in my book now.
Thank you very much. You just made me lose the best IMO anime batch encoder out there.

[LAIN]

wierd that you have a buch of error, i'v been encoding with realanime 4.1.2 for more than 3 weeks in a row 24/7 and never have any error. did you try to desinstall, remove all files in program files\realanime 4 and reinstall it new. i'v been having error until i do this and after this no more error.

I can't force you to use realanime 5, this is decision that were made by both of us (even that i didn't totally agree on his decision and i'll continu to use realanime 4.1.2 because of the mkv output and multi track support) at first real anime 4 (previously LE) was supposed to be "light edition" and because of user requests we do modification and add a lot of features (and it is still easyer to use than realanime 3.x). ALSO because of that we encountered a lot of error and with the help of ppl we were able to correct a lot of them. a buch of error was the result of the log unit that didn't free itself when realanime closes.

That is why we have finally decided to only ad MP4 ouput (easyer to support and to develop) and a complete new structure with only the features that we wanted, if there is people that is interested to use our program the way that we develope it it's awsome, if people dont want to use it, there is older version that work (almost all the time) correctly or, if you really want to have something custom made, program your own batch encoder.

[anne_so78]

if you really want to have something custom made, program your own batch encoder.
Dude, chill... No one here's gonna program their own GUI. We saw something good (RealAnime) and we'd like to see it become better and better with every release. Now, the way forward is certainly not stripping wanted features for a lighter and lighter version. Never should a newer version be inferior to an older version.
Okay, on the one hand you want a small and simple program that is easy to download and easy to use and easy to develop. On the other hand, some may want to customize various features and would prefer an advanced version. RealAnime4 contained various features that I'm afraid those may disappear in RealAnime5. This is ridiculous, not in my humble opinion, but as a fact. It makes no sense because all the code for all the features is already available. If the developers of RealAnime think that this is better because it is easier to develop, then why not ignore the 'advanced' features in the process of developing. This, I'm sure is the same as developing a 'Lite' version. If the developers think it still is better to strip down RealAnime 5 because the package is small and with minimal options, so it must be easy to use, to this I say > why not create a 'Basic' or 'Lite' RealAnime5 and an 'Advanced' RealAnime5. Even better, why not incorporate the two profiles in one program, if download size is not a big issue. If the developers of RealAnime are feeling too lazy to continue this 'RealAnime5 Advanced' project then at least take the exact code from the latest version of RealAnime4 (I think the latest version of RealAnime 4 actually works, and not that it is completely unusable...) and call it 'RealAnime5 Advanced'.
So there you have it, a RealAnime where only essential features are incorporated in a very user-friendly interface, and a RealAnime where every feature (or at least every feature in RealAnime 4) is available to tweak, but which may contain more bugs...
Everybody's happy...

[Sharktooth]

IMHO ppl should not criticize what they get for free...
However i would have called the actual RealAnime 5 just RealAnime LE (or Light).

[anne_so78]

IMHO ppl should not criticize what they get for free...
Of course they can, and they will... That's one of the reasons these boards exist right? To comment, suggest, and criticize if necessary. The fact that something may be free or not here, is irrelevant...

[Sharktooth]

I mean useless criticism in place of constructive criticism.
It's like pretending something from someone who does owe you nothing.

[anne_so78]

I mean useless criticism in place of constructive criticism.
It's like pretending something from someone who does owe you nothing.
I don't know how you got that impression:confused:

[Sharktooth]

Well i was referring to the Eretria-chan post: http://forum.doom9.org/showthread.php?p=831484#post831484

[LAIN]

@anne_so78

I understand what you are saying, we are not lazy about developing any program. We are just doing program that suits our needs. We do it basicly for us and if there is other people that want to use it and that fits their needs it's ok with us.

For develloping 2 different version of realanime "light" and "advanced" it like doing 2 time the same program, if we want to do a "advanced" version we would probably made 1 version and no "light edition" it might be confusing for some people to see realanime 5 with less feature than the 4, but we wanted to have a light program with features that we want to use. The current features that realanime 5 have may or may not stay the same, there might have new features added as the developement goes.

We appreciate all the testing and critics that you can give to our programs and all the testing that people can do to with a bunch of files that we dont have, this is fabulous and we are grateful for this. But the only thing that we would like to be considered for, we (me and sirber) are the only programmer on realanime (except the programmer that i dont know that work on xAnime on c#), and sirber does the major part of it everytimes and at the end of every project he sais that this is his last one and when he start a new project, people ask for a ton of features that he include and people always want more. I can understand that normally you have more features with version, but we do personnal developement and we are not a compagny or even payed for this time and for all the features that people request. we do it for fun and enjoy doing it.