KVCD Predictor
 

I've been working on it and have most of it done, just need to implement the various "Get this from there..." functions. Here's a screengrab to whet your appetites:

http://www.digitalfaq.com/archives/error.gif

You can expect the first release today :).

Wow...That looks GREAT!
Kudo`s to you, and all that put in the work!...http://www.digitalfaq.com/archives/error.gif





***************************************
They can put a man on the moon,
but they still can`t put a tin pan in a microwave.......UNKNOWN

Beautiful :lol:
You could calculate the audio file size automatically, by just dividing the number of frames by frame rate. That will give you total number of seconds. Then the user just selects audio bit rate ( 128, 160, 192, etc. ), and multiply bit rate by seconds, etc to get audio file size automatically :idea:
Anyway, that looks AWESOME :) :)

-kwag

I was going to do that, and then I thought "what if they're using VBR?" but I guess none of the templates call for that. I'll implement it now :).

When DVD players support VBR MP2 audio, then we'll do a audio file prediction formula, just like we did for video :lol:
Same principle. Different samples at different time intervals ;)

-kwag

I don't think that's necessary... there are not a whole lot dvd players to support that, and you don't save a lot of MBytes with VBR sound anyway...

First release
 

Yes, it's the moment you've all been waiting for ;). Here's KVCD Predictor 0.1 (and source code), ready for you all to pound on.

Please read the accompanying documentation. It's pretty easy to install, but you will need the .NET runtime if you don't have it already. There's a link in the readme.

I've established it's fairly well-behaved and doesn't seem to crash unexpectedly or get drunk and insult the in-laws, but I've not done extensive testing on the actual algorithm and the results it produces. This is where you guys come in :). Feed it as many values as you can think of, work out the result by hand and see if it matches what KVCD Predictor comes up with. Do some encodes with its recommended sample size and see if the final encode will really fit on that number of CDs.

Bear in mind it uses the exact length of the CD, which can be calculated with the following formula:

bytes = seconds * 75 * 2324

where seconds is, obviously, 60 * minutes, or 4800 for an 80 minute disc. Thus an 80 minute disc holds precisely

4800 * 75 * 2324 = 836640000 bytes

Also be aware that any reference to "megabyte" or "kilobyte" means 1048576 bytes and 1024 bytes respectively, so that if Windows Explorer says your audio file is 95.6mb, that's the value you enter. The 1024/1000 difference does not effect the final calculation, which is all done in bytes anyway (if you don't know what I'm talking about you can ignore this whole paragraph).

In this version the "Get movie length from source file..." option doesn't work, because it's going to be a lot more complicated than I imagined (for programmers amongst you, I have to learn how to write a managed C++ class to access the Video for Windows framework. Any hints appreciated :)). I'm going to work at it though, and hopefully it'll be ready for 0.2.

So, pound away. Use it and abuse it and let me know what happens. It's likely some tweaking will have to be done, but that's what an alpha release is for.

Have fun :).

P.S. Kwag -- could you please mirror the binary package for those who can't access my site at the moment?

Edit: Removed links to old versions.

Oh, and by the way, feel free to suggest better names ;).

Re: First release
 

Mirroring in the next five minutes ;)
I'll post a note in the "What's Happening" section and on the main page.

Thanks :D
-kwag

Re: First release
 

Excellent. I'm very eager to hear some feedback :).

Main page at www.kvcd.net updated.
Mirrors updated.
"Whats Happening" updated.
;)

-kwag

Great job SansGrip! :D

One thing I notice is the est. sample size is ~24mb less than 800mb and multiples thereof with scale factor @ 1.0

i'm using this formula:
MPEG size = ((Total frames/Framerate)/100) * (MPEG sample file size * scale factor)

again, good work and sorry if my math is wrong! :wink:
-ren

Hi SansGrip,

I just tested the program, and the audio calculation is perfect, but not the video. My #frames is 173097 / 23.976 / 100 = 72.195. My audio at 128Kbps, selecting one CD of 80 minutes, gives 112MB. That is correct.
Now for the video. 800 -112 = ~688MB for video. That's the estimated size. So if we reverse the formula: 688 / .95 / 72.195 = 10.03MB for the sample size, but the program calculates 8.87MB.

-kwag

Hi SansGrip,

KVCD file predictor needs .NET to run and the above quote is from Micro-
soft. :( So myself and others will not be able to use your fine program.
I use Win ME. :)

-black prince

New version
 

@rendalunit & kwag

Yep, you're right. Here's 0.1a ;).

(In case you're curious, I was adjusting the media size to compensate for the system stream, which is what you do for bitrate calculation but evidently not file size prediction :). I just took it out and did a couple of tests and reversing the result manually seems to be correct now.)

@black_prince

The SDK (Software Development Kit) requires Windows 2000/XP, but the actual framework (the runtime libraries) work on the other versions too. You should be able to find a link to it on that page I provided -- if not, you can get it through Windows Update (or here for the English version) and I'll fix the link in the doc.

Edit: Removed links to old version.

Hi SansGrip.

Almost!, it's still a little low. The result for the example I posted above, should give a sample size of 10.03MB. But the result is now 9.03MB :!:

-kwag

I'm really living up to my nickname tonight ;). I'll look at the source and try to figure out what I did wrong...

Edit: I'm multiplying by the scaling factor instead of dividing. 0.1b coming up ;).

Another new version??
 

Here's 0.1b, which should now produce the correct results...

At least, on kwag's test data it produces 10 -- not 10.03 -- which, after stepping through the code, is actually the more accurate value given that an 80-minute CD isn't quite 800mb (it's more like 797mb).

Hopefully this is the last update tonight ;).

Edit: Removed links to old version.

BINGO :lol: *** Jack Pot ***, you hit it right on the nose :mrgreen:
Updating mirror now....

Edit: ... Done!

-kwag

...which leads me to the question, should there be a facility for specifying a custom CD size, for those who like to overburn?

Also, wouldn't it be more logical and intuitive for a "scale" factor to be multiplicative? That is, instead of dividing by 0.95, multiplying by 1.05?

Also, @kwag, what do you think of the idea in the readme of some kind of formula to give a guess as to a good CQ/bitrate for producing a sample of the desired size? Too difficult?