ReJig 0.5 Released

[Rombaldi]

Originally posted by IvIark
One thing that I think would be handy though is to be able to choose the display type that is specified in the IFO. 4:3 films are sometimes captured at 528x576 pixels which when displayed as 16:9 pan scan show up as a normal 4:3. At present you have to edit the IFO so that the DVD will use pan scan as default.


Don't edit the IFO, use ReStream (http://shh.dvdboard.de/restream.html) to change the MPEG2 headers in the M2V file and you're good to go (Tmpgenc Author will pick it up as 16:9 and act accordingly)

[IvIark]

Don't edit the IFO, use ReStream to change the MPEG2 headers in the M2V file and you're good to go (Tmpgenc Author will pick it up as 16:9 and act accordingly)

The actual aspect ratio isn't the problem, it treats it correctly as 16:9. The problem is that by default, Rejig sets the display mode to pan-scan AND letterbox, but only pan-scan displays it correctly as full screen 4:3. So if your DVD player defaults to letterbox and you don't edit the Rejigged IFO first, then you'd have to manually put the player into PS mode to show it correctly.

It isn't a big issue as editting the IFO literally takes seconds, but it's just a suggestion to make Rejig more versatile.

Mark

[Makira]

Originally posted by TCmullet
[...] EVERY result with the new engine gives terrible results no matter whether it's 99.7 or 100.0 percent. I get very conspicuous pixelation in every file, but none with the old engine in either 0.5c or 0.5d. Even low-motion looks very bad (pixelated)... [...]

I've found the reason why. This is due to the alternate quantisation table, which minimize the delta between original value and recompressed value, by sometime using a value higher than the original. While this really improves psnr, the result is less pleasing to watch since it kinds of introduce noise into the image.

It seems psnr isn't always a good measure of quality...

I've updated the engine on my side, fixed this, and added a few other things.

http://www.info.polymtl.ca/~anmis/m2vrequant_291203.tgz

@Nic: I would suggest making i_factor, p_factor, b_factor, i_min_stress, p_min_stress and b_min_stress user definable via a setting window (let the user choose his own value, or the presets). You'll also notice the presets are now dependant on the factor used.

[TCmullet]

THANK YOU Makira! With NO disrespect to E-male, I just knew something had to be wrong if 100% caused deterioration at all, no matter what kind of source material.

@Nic: Maybe you could put Makira's new engine into the same release that will improve the size estimation.

@E-male: I do plan to go back and read your posts-- I'm sure it does apply albeit more so with lower factors such as 70, 80 or even 90. Any deterioration at all at 100% just didn't seem possible. (To me.) And as far as source material, the footage in question had plenty of occasional head shots (for enough seconds) that had little or no motion in them. That's what threw me-- I figured the problem was with the hi-mo of vball, but the lo-mo was just as bad. :)

[dragongodz]

Makira - how did i know you were going to do that to me ? i had just made some changes when yopu did the last update so put it on hold. then Nic updated so got the source and finally managed a little time to move the changes to the new engine for people to test. then BANG you do it again, another update. :)

will be busy for the next few days but i will do the changes AGAIN once Nic has updated.

oh and i disagree with the idea of having people having to put in their own factor amounts as it is more likly to lead to possible confusion and bad results. wait for the changes i want to add and then lets see from there.

[Makira]

about the alternate quantisation table:

my test shows that the alt table is probably better on samples without noise/grain, but amplifies the noise otherwise.

Since it is currently difficult to distinguish between low/high noise material, the lastest update completly disable the alt_table.

This may not be the best way to go..

So I'll try something tonight to see if I can make a dynamic choice about using the alternate table or not, and possibly post an update - I just got an idea.

dragongodz, wait a few hours :P

[TCmullet]

Makira, your comment about noise makes me want to comment. I have suffered the "mistake" of not having a multi-thousand dollar tv monitor. Cheap tvs smooth over noise. That's why EP made it so popular as a VHS tape speed; most folks couldn't see any noise. But at least twice in recent years, I've been disappointingly alerted that my own means for discerning noise were less than adequate.

My captures are from analog cable tv, and there is definitely more noise in the very best signal than in the worst DVD. Most of the folks on this board appear to be dealing with backing up their DVDs, whereas I don't even have a player. I have tons of CD-Rs with a zillion hours of mpeg2 video. And before that started, I had (and only a few months ago counted) over 750 VHS or S-VHS cassettes, the vast majority containing stuff either live (camcorder) or off the air. It has been rather disappointing to me that I can't get 1 hour of 480x480 video on an SVCD. I'm inclined to credit it all to subtle invisible noise that I can't see on my $700 monitor, or measure electronicly in anyway. I can only see how bad the picture gets when I encode or reencode to a smaller size. Typically, even when reducing to 352x480, I still can't get to that goal of an hour per disk with a clean picture. Even with lots of NR filters, etc.

But DVD is another matter. It appears that DVD is much cleaner than anything I can record from cable tv. To preserve a clean picture of volleyball games from cable (espn, sunshine, etc.) I have had to increase the average bitrate to 4 and even 5 Mbits/sec EVEN with a pixel ratio of only 352x480. (Maximum bitrate around 7.)

I guess I'm dumping all this story on you just to emphasize that you are very right about noise being a factor to consider.

[Makira]

Nevermind the idea: while the alt table does boost the psnr, it just doesn't look as good. Last update is best imho.
I don't intend to touch the engine anymore, at least for some time.

[unixfs]

Makira,
what's the use of the Logfile.txt?

Is it the first step towards a 2-pass code? :)

[DaddyC]

Hi,

i tried ReJig on my laptop euquipped with a fat32 formated hdd. i quess you can imagined what happened. the demuxed video never gets bigger then 4gb (because of the filesize limitations). so the whole movie never gets stored unless its smaler than 4gb.

so i think file splitting should be an option.

[pieroxy]

Hi Nic. Great job, I just can't wait for v1.0 ;););)

Just one comment with my tests so far. I have only tested the Author feature, and to answer "Amnon82" post on the first page of the thread, it is reeeeaaaaally slow. The problem is that it does it in two passes: 1 pass generate a "Mux.vob" file in the target dir, another pass then split it in the VTS_01_X.VOB in the VIDEO_TS directory. There seems to be a third pass, but I couldn't understand its meaning.

One might think this two pass process will take twice as much time, but one might be wrong ;) The thing is I have three hard drives in my machine. Copying one 1GB file from one HDD to another takes 2 minutes. Copying the same file from one HDD to the same HDD takes 10 minutes. 5X the time, due mostly to seek time.

If we could just specify an additional directory for this "Mux.vob" file, let it be called "Temp files directory", that would divide the time taken by the recompress by 3 (at least, for anyone having more than 1 HDD).

Of course, the perfect solution would be to split the big VOB on the fly :p

My $.02

[pieroxy]

@TCmullet

"It has been rather disappointing to me that I can't get 1 hour of 480x480 video on an SVCD"
800MB is a small container, especially for hi motion full screen video. Plus, the max bitrate of an SVCD isn't what I would call "large". Not mentionning that at the max bitrate you get 40 minutes...

"I'm inclined to credit it all to subtle invisible noise that I can't see on my $700 monitor"
A bad (read: noisy, shaky, etc...) source just force you to have a higher bitrate... But keep on reading...

"I have had to increase the average bitrate to 4 and even 5 Mbits/sec EVEN with a pixel ratio of only 352x480."
In my experience, 352x240 gets a reasonnable quality (for full screen hi motion NTSC video, not film) at around 2MBps, 2.5 being really comfortable. So your numbers seem reasonnable. And I am talking about a DVD source material over here, not just a bad VHS. Maybe the noise in your VHS is not the reason for your failure to get 60 minutes of video on one CD. Maybe MPEG is.

[dragongodz]

Makira - just had a quick look at that last update. ah you read my mind. i see you have changed the frame type factoring for different compression factors. that is what i was working on but mine is percentage based(since rejig uses percentage) with finer granularity. hmm will have to see if i can just redo mine to factor or maybe convert what you have to percentage when i get the time.

did you read before about my ideas on improving quality ? let me know if you are interested in hearing my thoughts on these things. :)

[Makira]

Originally posted by dragongodz
Makira - just had a quick look at that last update. ah you read my mind. i see you have changed the frame type factoring for different compression factors. that is what i was working on but mine is percentage based(since rejig uses percentage) with finer granularity. hmm will have to see if i can just redo mine to factor or maybe convert what you have to percentage when i get the time.

did you read before about my ideas on improving quality ? let me know if you are interested in hearing my thoughts on these things. :)

First I would suggest that we work with factor based instead of percent based: turning a percent into factor (and vice versa) is easy (if you have 70%, or 0.70, just do 1/0.70 = 1.43 and you have the factor). You only have to change the percent to factor once, while if we do it the other way, there'll be many place where we'd need to convert values, and we'd have to do it each time...
(I hope you noticed I make a linear interpolation between presets)

Second, I did read your post about improving quality. A few things comes to mind:
-about using different quantisation matrices: while this would certainly be an improvement, I'm not sure by how much, and there is several problems with this idea: each frame would have to be requantised, even at stress 0, even if we reuse the same quantiser. This would slow things down, especially at low factors, since currently I and P frames are likely to be copied as is. It also means some gops could finish bigger than before. Series of black frames comes to mind. You may also have noticed the current code will copy a slice if it ends up bigger than before (that happens maybe on 0.5% of the slices), well this could not be done anymore. This is a rather big problem since DVDRemaster _requires_ that each frame is smaller or equal than the original (and vbv/ps-std also requires this, unless you want to remake your own vbv control). And finally the speed impact would be non-negligeable, since that means at least one multiplication and one division.

-about deep analysis/target size of each frame/2-pass/etc. This would be nice, but the speed impact is obvious, it'll take at least twice the time, or more. Also, I'm not conviced about the quality improvement, for one main reason: we can always consider the original stream to be the first pass! And this would require big changes to the current code, a lot more than changing quantisation matrices

Personnally, I think the best improvement we can do, other than tweaking factor and min stresses, would be to have a better bitrate controller (a pid (http://www.tcnj.edu/~rgraham/PID-tuning.html) or something smarter). For exemple, maybe instead of adding a value to the orig quantiser, we should multiply it bya value. Or take the the derived value of the stress factor into account (this is currently done with m2vdownsizer). Or maybe using recompressed size of the slice after recompression against its original size for feedback into the bitrate controller.

[dragongodz]

Makira - yes i noticed so i would think my tweaking would only gain small increase in quality if any. still worth playing with to see though. :)

well rejig already has the desired percentage size done(percentage_x variable) which is what i was using for frame type factoring variation. i will probably just play with your presets for now though and see what that brings.

the main method i was advocating(for at least exploration) was the compress frame to the desired size. that is if you were compressing to 50% of original size then you would read frame, reduce frame, measure is frame the desired reduced amount, if not reduce some more, once it is(or even slightly more) then write frame and proceed to next. from my understanding this is exactly what dvd2one is doing with its CBR(Constant Bitrate Reduction) method. the up side is better quality especially for large/long movies and accurate sizing. down side is yes it takes longer(but it should be worth it), I frames and P frames compressed even at low compression amounts(that could be forcfully stopped based on compression amount, so frames would be just copied so never bigger, with B frames compressed slightly more to make up the defecit). actually my proposal was also for weighted amounts by frame type. that is I frames get compressed slightly less than target and B frames slightly more, then tally at end of GOP to see if target reduction achieved and if not then increase B frame compression amount to make it up or if over compressed then reduce slightly to payback the extra bits, if not enough then then I or P frames could also be used for payback except for low compression where they wouldnt be compressed anyway. this brings a slight variation in to the sizing but should benefit quality because I frames quality should be better maintained, especially for large amount of compression.
another thing i havent mention here(i did to Nic by email) was skipped frames(total skipped macroblock for a frame). this would be interesting to investigate for use with very high compression, that is compressing to 40% of original size or smaller. something like make every second B frame of a pair skipped. easy to set in that when read frame if it is I or P frame set pair variable to 0 and if B frame and pair is 0 then set to 1 and compress as normal. if pair is 1 already then make skipped and reset pair to 0. you would lose some smoothness in playback but gain extra bits for the other frames to increase their quality slightly. again this is just something that i thought would be interesting to be investigated. :)

actually i am curious, is anyone else interested in all this or are you skipping past when you see us talking about this stuff ? :D

[Vapor]

Sorry for going backwards a bit here - just trying to save some time for certain users.

Originally posted by IvIark
Rejig can correct that delay though, or a tool like Ac3 Delay Corrector which can handle MPA. It'd take less time to correct the audio than to remux.

I know this "should" work but in practice only 50% of files input into TMPGDVD Author work correctly if seperate vid/aud are used, regardless of AC3 delay correction.

The problem is not with audio delay usually. The main problem is incorrect timeline, TMPGDVD either gets it wrong or detects no frames at all. This makes chaptering impossible.

These problems occur in near on 100% of cases when the video is NTSC-Film type with pulldown.

Muxing with BBmpeg corrects these problems in 100% of my cases (over 100 mastered DVD's).

It's worth trying TMPGDVD first of course as sticking the files in and checking the timeline in the chapter window takes only 30 secs. If it's wrong mux with BBmpeg.

Another thing in TMPGDVD, make sure you do actually try and add chapters (I use add chapters every 5 mins as a test) as in a few cases it will only produce the full time line after inserting the chapters.

These sort of muxing/mastering problems are also been discussed in the following thread: http://forum.doom9.org/showthread.php?s=&threadid=64060

[E-Male]

ok, i'm still not perfectly recovered from a birthday-party (not mine) and new-year, but i wanna state i'm still alive
and i got 2 things to say

first a problem:
rejig 0.5e
DVD: blair witch project, rc2, pal, german
mode: DVD Backup
keep all tracks (3) and subs (1)
no transcoding needed
after multiplexing (when i expected sub-multiplexing) it stopped and left me with some files, all ~19k if i rememebr correctly
i tried again with same result, but deleted everything
i'll try to reproduce it again and report exactly what happened

and about the engine:
before i start: i got no real idea about about the engine, so i might be totally wrong with my thoughts
the idea is this: sicne noise seems to be a factor, maybe a option for telling the engine how noisy the source is could help, with options like "sofr/video tape" "perfectly clean/digital image" "clean/good film" "normal with film grain" "grainy/old film" "noisy/capture".....
just an idea

CU
E-Male

p.s. just out of curiousity: could the transcoder remove the color onformation (set all to "grey") and so act like a greyscale filter without reencoding?

p.p.s. @TCmullet: sorry, read your post to quickly and misunderstood your point

[pieroxy]

Hi there, another minor bug (0.5e). At first, I thought the reauthor mode didn't work at all, because it would leave me with all my VOBS, none of the IFO/BUP and crash in the end. Of course, it was my mistake, as I figured later, and the reason was I was out of disk space on my C:\ drive...

When I came back, there was almost 1 GB free because one process that generated temp files was done, and had erased them. So I was there, ReJig crashed, my DVD incomlete and 1GB free on my HDD. It took me a while to figure this one out ;)

Well, just a nice dialog "Not enough disk space" would be perfect for such a situation...

Of course, that is not a P1, blocker or anything...

[Makira]

Originally posted by E-Male
p.s. just out of curiousity: could the transcoder remove the color onformation (set all to "grey") and so act like a greyscale filter without reencoding?

I guess so, but what for?

[Joe Fenton]

Originally posted by TCmullet
I have suffered the "mistake" of not having a multi-thousand dollar tv monitor. Cheap tvs smooth over noise.

You are mistaking a TV for a monitor. The purpose of a monitor is to display the incoming signal exactly as-is to the best of it's ability. The purpose of a television is to display the incoming signal in the most pleasing manner possible, even if it means altering the signal. Cheap TVs don't smooth over noise, ALL TVs do. Expensive ones do it better and by more expensive means.

When you watch TV, you want the "best looking" display possible. When you use a monitor, you want to see the details of your display as clearly as possible. When doing video encoding, you want to check your results on a monitor, knowing that on a TV, it will look better. AVIs which are blocky and noisy on my computer look rather nice on my TV set.

[E-Male]

the greyscale question was mostly out of curiousity
but the purpose would for example be removing chroma noise from black&white caps or similar things

[TCmullet]

Originally posted by dragongodz
...actually my proposal was also for weighted amounts by frame type.I very much cast my vote FOR this and AGAINST any scheme where all of reduction is aimed at B frames and none at I frames. I want to be able to single step from frame to frame and not notice a significant quality change. Btw, this is why in the Divx world, I'm not interested (much) in psychovisual enhancements--they all rely on continual motion to obscure their artifacts.
actually i am curious, is anyone else interested in all this or are you skipping past when you see us talking about this stuff?Although a lot of it goes over my head, I do enjoy reading it and possibly learning something. Keep it up. Then someday when I am more knowledgable, I'll reread this thread and say "Hey NOW I know what he's talking about!" Yes, some of it I gloss over, especially when rereading it for purposes of making this post. But please keep up the good work. :)

[TCmullet]

Originally posted by Joe Fenton
You are mistaking a TV for a monitor. The purpose of a monitor is to display the incoming signal exactly as-is to the best of it's ability. The purpose of a television is to display the incoming signal in the most pleasing manner possible, even if it means altering the signal. Cheap TVs don't smooth over noise, ALL TVs do. Expensive ones do it better and by more expensive means.

When you watch TV, you want the "best looking" display possible. When you use a monitor, you want to see the details of your display as clearly as possible. When doing video encoding, you want to check your results on a monitor, knowing that on a TV, it will look better. AVIs which are blocky and noisy on my computer look rather nice on my TV set.Thank you for augmenting my slightly hazy perception of the matter. Yes, I've know that a NTSC video monitor is for us serious users to attempt to see exactly what's there. When I said 'cheap tvs smooth over noise', I meant that really old ones are inadvertantly doing that simply due to their limited bandwidth. I didn't know that expensive contemporary TVs do signal cleanup for viewing pleasure on purpose. (Drat!) Today's 30+ inch TVs at circuit city (actually a year ago was the last time I checked) show up more mpeg noise in my captures than my 1992 $700 25" Panasonic industrial grade monitor does with the sharpness turned all the way up! Now you're saying that if I ever "upgrade" to a contemporary consumer tv as my video monitor, I will be viewing thru all that smoothing crap. Crap!

The reason I simplify my comments by saying 'tv' is to distinguish 'video monitor' from 'computer video monitor'. I've spent a good bit of time earlier this year (oops last year-2003) on the Divx forum, and it seems that most of those folks believe in watching their movies on their computer! I am severely opposed to that practice and I voiced my reasons over there. So over there it was easier to say 'tv' than 'ntsc video monitor'.

And btw, I take polite exception to your AVI comment. I had MAJOR disappointment a couple years ago when I painfully discovered that files that looked great on my S-VGA monitor (computer), looked TERRIBLE on my ntsc video monitor (tv). So I NEVER trust my computer monitor--I always get it out to my ntsc set so I can SEE all the potential problems my file may have (noise, interlacing errors, etc.). (I might watch my files on the computer a bit more if it could properly show an interlaced signal at 60fps.)

And btw again, I also dislike the overscan that most tvs do. My monitor has it but not as much.

(Sorry y'all if this is too off point for this thread.)

[TCmullet]

Originally posted by E-Male
the greyscale question was mostly out of curiousity
but the purpose would for example be removing chroma noise from black&white caps or similar thingsI've thought about this a number of times over several years. Why encode color signal & noise if it's a B/W show? Unfortunately, an mpeg-knowledgable friend claims that the lack of color per se won't improve compression as mpeg is not particular color-sensitive (my term). But it'd be nice if you guys could prove him wrong. Especially if we can do it in Rejig (as an option switch of course), rather than during a re-encode (such as with Tmpgenc).

[E-Male]

well, i didn't mean that it would increase the trancoding quality technically

it would just look better for the eye

[RB]

Maybe another way to improve quality is to try to figure out how InstantCopy does such a beautiful job most of the time :) Maybe this article (http://www.cdfreaks.com/article/114/2) can help:

Q: Your InstantCopy product is slower than competing products like DVD2one or DVDShrink?

A: You are comparing apples and peaches. While InstantCopy is a full featured transcoder with highest quality output, both programs you are naming do only a quick “requantization” and ignore the lower quality and signal errors in the resulting stream.

Q: I don’t understand. Can you explain the difference in detail?

A: Well, basically MPEG Video is encoded in groups of pictures called GOPs. In every GOP is a reference frame followed by several difference frames. While the reference frame is encoded as a full picture the difference frames contain only the differences to the “last” frame. While encoding every frame is “quantitized” – this means that small, almost unnoticeable differences in the signal are removed. Both InstantCopy and competing programs change the quantization process. However, InstantCopy is the only program that takes the changes done into account for the following frames. This means that additionally to the “quantization” the whole frames needs to be decoded two times and encoded one time which is indeed very time consuming. However, if you only do the quantization the picture quality gets worse with every frame until the next reference frame is decoded – which is the famous annoying "pumping".

[MvB]

Hi Nic,

all DVDs i author with your tool or ifoedit won't play in my Liteon LVD 2001. It plays the first second and than freezes.
Because i have another player who plays the discs fine i didn't recognize that earlier.
Do you have an idea why? I author pulldowned progressive material like in nearly every normal NTSC Movie DVD.

Thanks
MvB

[E-Male]

every original ntsc dvd i got is NOT pulldowned

also, does that player play other burned dvds?

[MvB]

i've learned that all NTSC-movie DVDs are 2:3 pulldown enabled, that means the coresponding bits for the repeation of the halfframes are set.
If you try to play a stream that is not pulldowned you get a very choppy picture

[pieroxy]

@MvB:
No, not all NTSC-movie DVDs are 2:3 pulldown, even if that is the right way to do it. Most of them are however.
If you try to play a stream that is not pulldowned you get a very choppy pictureNot necessarily. First of all (assuming your stream is 23.976 fps), this kind of stream is not DVD compliant. So it is not even guaranteed that such a stream will play in a DVD player. Depending on the player you will have different results ;)... Mine play them fine.

[ffroms]

I have to report, again, problems with subs and authoring. Now I have everything working but somewhere in the middle of movie sub simply disappear and after few seconds player (PowerDVD) freeze. Home DVD player acts a little different (jerky playback) but result is the same. I'm guessing that there is some sub muxing problem couse if turn off sub everything is OK. I was using sub2sup and used simple text file *.sub. I've even tried to author DVD with Maestro and rip sub from that DVD and mux with ReJig but same problem happens but on different part of movie. Movie is NTSC if that helps.
Oh, yes. There is still problem/crashing if you try to author two DVD without exiting ReJig completely.

FFS

[djan]

Originally posted by JvD
My first test on 0.5

2. I tried backing up (DVD Backup feature) Magolia (appr 3h long) and it ran fine from start to end. BUT the result was only a half movie (second half).
Same problem for me with Traffic using ReJig 0.5e.

[Joe Fenton]

Originally posted by TCmullet
Now you're saying that if I ever "upgrade" to a contemporary consumer tv as my video monitor, I will be viewing thru all that smoothing crap. Crap!

If you look at the first big-screen TVs to come out, they had a VERY blocky picture. To make the pictures look better, they started doing something akin to deblocking. Cheap TVs just do simple interpolation and look a little blurry. Expensive TVs use digital circuitry to really implement some heavy duty smoothing algorithms.


And btw, I take polite exception to your AVI comment. I had MAJOR disappointment a couple years ago when I painfully discovered that files that looked great on my S-VGA monitor (computer), looked TERRIBLE on my ntsc video monitor (tv). So I NEVER trust my computer monitor--I always get it out to my ntsc set so I can SEE all the potential problems my file may have (noise, interlacing errors, etc.). (I might watch my files on the computer a bit more if it could properly show an interlaced signal at 60fps.)

Uh, you got my statement backwards... good AVIs will look bad on TVs because they lose detail. I said bad AVIs look "better" as the TV covers many of the imperfections.

And btw again, I also dislike the overscan that most tvs do. My monitor has it but not as much.

Yep. I don't like that either. I open my TVs up and adjust the overscan to an acceptable level. It helps if you spent high-school working in a TV repair shop. :D

[djan]

Will the problem of encoding only the end half of the movie be resolved soon please ? Because it's so annoying. Thx.

And there is also another bug in Ifo Mode. When you deselect chapters, you go to another vts and you come back to that vts, the program doesn't memories the selection you did just before.

But otherwise the program rules !!! Very good Job Nic.

[Nic]

@djan: On all my DVDs (that I've tried) it works and does the full movie..If you dare to part with your Traffic DVD or feeling particulary generous ( ;) ) and feel like buying and sending me a copy then I could fix it ASAP....But I can't replicate it yet :( You may have to wait until I come across one that shows the same problem...

-Nic

[djan]

Ok, thx Nic, I sent you a private message about Traffic.

And what about the second problem in Ifo Mode ? Do you know about ?

Thx.

[DDogg]

... and feel like buying and sending me a copy then I could fix it ASAP Nic, maybe you will break down and do that Amazon wishlist I was beating you up about? :) (you need some NTSC stuff!) :D It would actually help folks get stuff to you a lot easier for them while maintaining address privacy for yourself.

[sidders]

I have been away from this for a few weeks, and decided to give Rejic 0.5e a try. I opened up the rejig data file created with DoItFast4U and ReAuthorist, and it gave me a size for my 2-pass encode. I left the size at this, let Rejig do its thing, then imported into Scenarist.
I found though that my final size was about 150mb too big. I reduced it in Rejig and did it again and it was fine.

My question is, how accurate is the filesize imported into Rejig? When I use the 'big 3', my file size is always correct. Am I doing anything wrong? Does the Rejig data file give Rejig an accurate figure to work with? I notice that the 1-pass is given in terms of a %. Is this accurate?

Sorry for all the questions, but I'm quite new to Rejig - usually use CCE.

[bigjohn]

Rejig is crashing on me as well.

I took a ReplayTV mpeg file and loaded it in file mode.
I ran the 1 pass function on the file, then Demuxed it.

Then I loaded the m2v and the mpa file into the Author mode.

About 5 minutes into the multiplexing process the application crashes...

John

[bill_baroud]

quote:Originally posted by JvD
My first test on 0.5

2. I tried backing up (DVD Backup feature) Magolia (appr 3h long) and it ran fine from start to end. BUT the result was only a half movie (second half).


Same problem for me with Traffic using ReJig 0.5e.


are you sure you're not on a FAT32 system, limiting the file to 4gb ? :D

well sometimes you forget about things like that :sly:

[Nic]

(One of the things delaying the new release is a little message box that pops up and warns you when using Win9X and/or FAT32 ;) )

@bigjohn: Ill look into that, might be to do with the MPA muxing, I've never tried that with DVDAuthor...

@sidders: I dont know much about the DoItFast4U integration as mmgrover did that...I thought (& in testing) the engine produced accurately sized files...However, ReJig can't overly compress a file, so if it is supposed to be very small compared to the original it could end up being oversized.

@DDogg: You may well be right (As always :) ). I do need NTSC DVDs. English DVDs are so simpley put together as well. (Got a box set of DVDs from the director of Battle Royale for christmas hoping they'd have some wacky subtitle problems (but to no avail))

@djan: ReJig in IFO Mode can only work on one VTS set at a time and hence looses the information if your switching to another. It's not really a bug as such because of it.

-Nic

[TCmullet]

Originally posted by Joe Fenton
Uh, you got my statement backwards... good AVIs will look bad on TVs because they lose detail. I said bad AVIs look "better" as the TV covers many of the imperfections.I'm not sure I have your stmt bwds; I think I'm disagreeing with your statement that files look "better" on the TV. What I'm saying is that any file which may look okay in Wmp on S-VGA, MAY look bad on my industrial grade NTSC monitor. Or, 'bad AVIs look worse as the NTSC monitor shows all the crap that my S-VGA monitor won't'. I don't think my NTSC monitor is doing all that smoothing stuff you're talking about. However, it DOES appear to 'smooth' just by being 10 years old and weaker technology. BUT not as smoothing as my S-VGA monitor, hence my distrust of S-VGA. (I also haven't seen interlaced video properly on S-VGA-- I'm guessing the players drop a field.)

[TCmullet]

Originally posted by Makira
..I've updated the engine on my side, fixed this, and added a few other things.

@Nic: Could you please clear this up-- Does 0.5e have the updated "new" engine that Makira fixed apparently on 12-29?

[Nic]

That engine is not in 0.5e...will be in 0.5f. Already put it, just not released yet (looks good as well...definitely the best "new" engine, still haven't tested fully with the old engine)

-Nic

[djan]

Originally posted by bill_baroud
are you sure you're not on a FAT32 system, limiting the file to 4gb ? :D
No, don't worry, we are not so stupid.

[djan]

Originally posted by Nic
@djan: ReJig in IFO Mode can only work on one VTS set at a time and hence looses the information if your switching to another. It's not really a bug as such because of it.

So, imagine there are 3 VST and I choose the one I want and I begin the demuxing, will it only demux the one I was on ?

[bigjohn]

@nic

if you like, I can send you (or put on a FTP server for you to fetch) an M2V/MP2 combination that crashes your application... NTSC / US television.

John

[mmgrover]

@sidders

If using the lates ver of DoItFast4U, Rejig should be using
the ReJigData.txt file in 2 pass mode.


mike

[sidders]

I am using 1.4.0.0 - it did open up in 2 pass mode, but the filesize was slighly too big. Just adjusted manually by a little bit and it was fine. I just wondering whether this filesize is as accurate as CCE, as this method produces filesizes that are pretty much spot on.

[Rombaldi]

I think this is the longest we've gone without some update :D