MeGUI development

[shon3i]

@dimzon here is the log of muxing process

Log for job job2

mkvmerge v1.7.0 ('What Do You Take Me For') built on Apr 28 2006 17:19:57
'Firewall.mkv': Using the Matroska demultiplexer.
'track 07.aac': Using the AAC demultiplexer.
'Firewall.mkv' track 1: Using the MPEG-4 part 10 (AVC) video output module.
Warning: AAC files may contain HE-AAC / AAC+ / SBR AAC audio. This can NOT be detected automatically. Therefore you have to specifiy '--aac-is-sbr 0' manually for this input file if the file actually contains SBR AAC. The file will be muxed in the WRONG way otherwise. Also read mkvmerge's documentation.
'track 07.aac' track 0: Using the AAC output module.
The file 'pera.mkv' has been opened for writing.

The cue entries (the index) are being written...
Muxing took 84 seconds.

so it's better to always use mp4 container for CT AAC

[berrinam]

Originally Posted by shon3i

so it's better to always use mp4 container for CT AAC

MeGUI already chooses MP4-AAC over RAW-AAC when there is a choice in MuxPathFinding. I think it is wrong and unreliable to (a) expect that mp4box is in WAAC's directory and (b) only allow mp4-aac output.

Also, I don't know if it is possible, but perhaps MediaInfoLib can detect whether an AAC file is SBR, in which case that problem goes away.

[Doom9]

There's another point to this: ctaac is the one aac encoder causing way more problems than any other. Since it's not any better than neroaac and costs the same, why do we even have it?
At some point, it's better to cut your losses.. your head starts to hurt if you try to break through the wall headfirst a couple of times and the wall just won't crack.
Just look at all the issues people are having with different ctaac versions and dlls, and the fact that we can't bundle them in autoupdate. It is very much reminiscent of the mess we had with neroaac prior to the commandline encoder. Actually, I tend to think it was a little less worse as things were stable with Nero, but are still changing with ctaac.

[SeeMoreDigital]

Hmmm!

My foot's in the other camp... I'm of the opinion that CT's encoder generates better sounding encodes than Nero's free encoder, especially when it comes to generating 6Ch AAC-HE streams!

Now when it comes to knowing whether or not an AAC stream is LC or HE, is not one of the biggest indicators the encodes "sample rate"?

EDIT: For example, if you are encoding from a 6Ch AC3 source with a sample rate of 48.0KHz, the 6Ch AAC-HE encode will have a sample rate of 24.0KHz. Like-wise, if you are encoding from a 2Ch CD-WAV source with a sample rate of 44.1KHz, the 2Ch AAC-HE encode will have a sample rate of 21.050KHz.


Cheers

[shon3i]

Originally Posted by berrinam

MeGUI already chooses MP4-AAC over RAW-AAC when there is a choice in MuxPathFinding. I think it is wrong and unreliable to (a) expect that mp4box is in WAAC's directory and (b) only allow mp4-aac output.

Also, I don't know if it is possible, but perhaps MediaInfoLib can detect whether an AAC file is SBR, in which case that problem goes away.

Ok, but dimzon makes enc_aacplus.exe to can produce mp4 files but only via mp4box and this work fine whitout any bug, so ct aac itself can't produce mp4 only raw aac and now no sense to use raw aac. if you use mp4 extension for aac that is wrong. If you can make somehow to detect sbr like you say, that will soloved the problem.

Originally Posted by doom9

There's another point to this: ctaac is the one aac encoder causing way more problems than any other. Since it's not any better than neroaac and costs the same, why do we even have it?
At some point, it's better to cut your losses.. your head starts to hurt if you try to break through the wall headfirst a couple of times and the wall just won't crack.
Just look at all the issues people are having with different ctaac versions and dlls, and the fact that we can't bundle them in autoupdate. It is very much reminiscent of the mess we had with neroaac prior to the commandline encoder. Actually, I tend to think it was a little less worse as things were stable with Nero, but are still changing with ctaac.

I agree with SMD, nero newer had good 6ch encoding aslo stereo is not so good, only where is better nero is maybe 48kbs, but i think aslo that licesing test on HA is not anymore correct because nero @ 48kbs now sounds whrose than on the test.

[daverc]

MediaInfo c# is ready.

Just put these files next to mediainfo.dll, and add a button in the gui.

Sources available on request.

[daverc]

Here is the code.
Original idea was found in staxrip.mediainfo.
Thank you Stax


Media tracks are List<TrackType>.

For instance, syntax to acces the codec of the first video track is

MediaInfo M=new MediaInfo(path);
string codec=M.Video[0].Codec;

You also get free track counter, and everything mediainfo can provide.

An empty string is returned when no information is available.

[bob0r]

Originally Posted by berrinam

0.2.3.2162
Commit by berrinam:
  - Fix audio-filesize-being-ignored bug in bitrate calculator
  - Fix AR calculation to be ITU-correct

Stable release candidate. Bugs, anyone?

Quick answer: No
The calculator is still very bugged. (You should test it a little)
In this case, fill in audio size, then change minutes then the audio resets to 0 (will file bug report if wanted)
In the the bitrate calculator is pretty important for custom encoding.

Long answer: No
Ill run by all visual and most logical functions very quick tonight. Too see if there are any unclean "bugs".

Then people should test some variations of default encodings and features(updates/bitrate calc/etc..)

[berrinam]

0.2.3.2163
Commit by berrinam:
  - Another go at the bitrate calculator

It seems to be fine for me....

[berrinam]

0.2.3.2164
Commit by berrinam:
  - Make the UpdateWindow fixed-size
  - Add ConvertToYV12() to the autodeint scripts

Right.... again, any problems?

[berrinam]

Could a moderator approve daverc's second attachment please, or could dave post it somewhere else?

[Doom9]

I approved the attachment. Being able to approve inline really is a major bonus of the 3.5 vbb series

[shon3i]

Originally Posted by berrinam

0.2.3.2164
Commit by berrinam:
  - Make the UpdateWindow fixed-size
  - Add ConvertToYV12() to the autodeint scripts

Right.... again, any problems?

Again Bitrate Calculator but now have minor bugs.

1. MKV and MP4 must have same bitrate for same settings because when i using mkv bitrate i always get undersize, the differences is about 2 bits

2. Audio bitrate values are non-standard, can you make only standard values like 16,32,48,64,80,96,112,128,160,192,224,256,320,384, etc

3. when i try to change from MKV to MP4 container in bitrate calculator, bitrate won't change for this 2 bits

[Doom9]

While the bitrate should be somewhat different between MP4 and MKV there's one thing to be kept in mind: you cannot accurately calculate MKV overhead prior to encoding. The exact formulas are in the container forum in a post by mosu as reply to one of mine.. the overhead depends on the distribution of frame types.. and you just can't know how many I, P and B frames you're going to get prior to encoding. Every MKV bitrate calc on the planet relies on assumptions that can be more or less correct, but no calculator is ever exact.

[shon3i]

Originally Posted by Doom9

While the bitrate should be somewhat different between MP4 and MKV there's one thing to be kept in mind: you cannot accurately calculate MKV overhead prior to encoding. The exact formulas are in the container forum in a post by mosu as reply to one of mine.. the overhead depends on the distribution of frame types.. and you just can't know how many I, P and B frames you're going to get prior to encoding. Every MKV bitrate calc on the planet relies on assumptions that can be more or less correct, but no calculator is ever exact.

Yes but when i use MP4 bitrate (+2bits per second different from mkv bitrate) and mkv container i always get choosen size, with mp4 bitrate i never get over/undersize, and aslo GordianKnot bitrate calculator, calcualte same bitrate for mkv like megui for mp4. So then in megui something wrong abut mkv calculation because must be same like mp4.

[berrinam]

Originally Posted by shon3i

Yes but when i use MP4 bitrate (+2bits per second different from mkv bitrate) and mkv container i always get choosen size, with mp4 bitrate i never get over/undersize, and aslo GordianKnot bitrate calculator, calcualte same bitrate for mkv like megui for mp4. So then in megui something wrong abut mkv calculation because must be same like mp4.

Woah, it is really hard to understand what you are saying. Nevertheless, it seems to be a problem with the MKV overheads, which is a known problem. Suffice to say, I don't see it either as drastic enough or as easy enough to solve immediately, so unless some other dev will look into it, you will have to cope, unless you can give direct instructions on what to change.

Originally Posted by shon3i

2. Audio bitrate values are non-standard, can you make only standard values like 16,32,48,64,80,96,112,128,160,192,224,256,320,384, etc

This isn't a bug, and all you're asking for is multiples of 16, basically. It steps in multiples of 16, but gets adjusted by some other calculations, which can skew this because of rounding errors. This is not actually a bug (it's just an interface detail) so I'm going to ignore this for now. You can manually enter your own bitrate if you want.

[shon3i]

Originally Posted by berrinam

Woah, it is really hard to understand what you are saying. Nevertheless, it seems to be a problem with the MKV overheads, which is a known problem. Suffice to say, I don't see it either as drastic enough or as easy enough to solve immediately, so unless some other dev will look into it, you will have to cope, unless you can give direct instructions on what to change.

Sorry berrinam for my very poor english, MKV must have same bitrate like MP4 because have similar overhead which is not so different, but in resulting bitrate must be same value. FOr example in GK for MKV and x264 bitrate is 1087.98 rounded this is 1088 which is bitrate of MP4 (and it's correct bitrate for both MP4 and MKV), but in MeGUI for MKV i get bitrate 1086.

Originally Posted by berrinam

This isn't a bug, and all you're asking for is multiples of 16, basically. It steps in multiples of 16, but gets adjusted by some other calculations, which can skew this because of rounding errors. This is not actually a bug (it's just an interface detail) so I'm going to ignore this for now. You can manually enter your own bitrate if you want.

Ok for that but try to type 128 and you get 127 in box, Why?

[bob0r]

Originally Posted by berrinam

0.2.3.2163
Commit by berrinam:
  - Another go at the bitrate calculator

It seems to be fine for me....

Mostly it works fine, here are some final reports/questions:
MeGUI Bug-Report Thread - audio tracks

[berrinam]

0.2.3.2165
Commit by berrinam:
  - Enable audio track 2
  - Fix the 15kbps bitrate increment to a 16kbps increment

I had a look at the actual calculation code, and it seems like some of it is wrong (according to www.alexander-noe.com, anyway), but it isn't a fatal error, so I think that can wait, considering that it needs some more work and testing.

@Doom9: What did you use to write the calculation code? www.alexander-noe.com has stuff about AVI and MKV, and it is mostly the same as what you have, but some of what you did now seems outdated (eg the MKV frame-size issues are no problem with MKV v2, apparently -- all frames now have 7 bytes overhead).

[Doom9]

I used the information mosu gave me in this thread: http://forum.doom9.org/showthread.ph...light=overhead
Page 2 and 3 contain the relevant details. I was never quite happy with the existing code and asked if somebody had a better idea.. if you have one, feel free to adapt the calculations.. they're really suboptimal.