[Rich A]

As most of you know, I've been around here a lot trying to help people with various RPTV to DVD problems. Lately I've had a few guys send me samples that were un-usable to them. I've not found ONE single (of the 8 or 9 now) that I couldn't fix. Every one was able to be used to generate perfect DVD source material. Recently I was working with another guy who had run into a brick wall with a very long video. I got the first part of his video last night and again have authored a perfectly playing DVD from it.


However his problem was a little different and something that can be difficult to fix. I've found an easy way to find, and repair the problem. Although this post is a little long due to my trying to explain it non-visually, the actual technique is simple. But you'll need Womble and DVD-Lab to do it. (although if you have some other fully frame accurate editor that will show you frame numbers you should be able to use that) The reason for using DVD-Lab is because of something that is a by-product of it's use and I don't know if you can use other authoring programs in it's place.


I'm going to assume you are familiar with Womble and DVD-Lab so I won't dwell on how to use those programs.


Let's start with the RAW RPTV mpeg. For starters, don't do a thing to it. No GOP fixing etc.


First De-mux it with Womble. I'll call the result Movie.mpv and Movie.mpa for example.


Now open up DVD-Lab. Import those Video and Audio assets.


Don't do anything fancy. We are only going to do a test compile JUST to find the problem area. Just drag the audio and video to the movie window. Like normal. Then double click on the menu icon and just add a text "Play" on the blank background. No need to waste time with buttons, chapters and such.


Link that PLAY text to the beginning of the movie.


Now do your compile. Make sure you have checked to use a separate work/temp folder in the DVD-Lab compile window.


If you have a problem, it will bomb out. (this is good) heh heh. This shouldn't take you more than a couple minutes to get to this point..


Close the error window. Click on the "stop" compile. And exit DVD-Labs.


Now look in the work/temp folder and you will see a *.vob file. Drag this file into womble.


Change the Womble format from "time code" to "Frame". If you don't know how, look at the right bottom of the womble mpeg window that is open. Where the time code is displayed. You'll see a little red cross there. Click on that and a window will open showing the mpeg parameters and in the bottom left of that new window is a place to select either time code or frame.


Now back to the mpeg window .. scrub all the way to the END of the displayed VOB. (you can hit the right bent arrow in the time/frame display box and it will jump there)


NOTE the frame number. THAT my friend, is the last good frame that DVD-LAB was able to compile. The next frame or frames have problems. It's usually just one or maybe two. Wasn't it wonderful of Oscar to have a "built in" bad frame locater?


Now close that out. Delete the *.mpv and *.mpa and the temp VOB etc. Just leave the original ReplayTV program stream intact. Load that original mpeg program stream back into Womble. Scrub to the exact frame you had noted.


At this point there are a few ways to fix it. The most accurate (and the one that has the least chance of screwing up your audio) is as follows


Let's say the "last good frame" is number 7636.


Mark THAT frame as the out point.

Copy that segment to the clip list.


Now scrub the pointer two frames to the right. Mark that point as an IN mark. Then scrub to the END of the video and mark that as the OUT mark.


Copy the 2nd half you've marked to the clip list.


You should now have two movie clips in the clip list that are the first half and second half of your video MINUS the two screwed up frames in the middle. (You may only need to eliminate one frame but I always start with two myself)


Now delete the mpeg window and drag the first clip onto the work area.

Drag the 2nd clip onto the 1st clip in the work area.


Now save the whole thing as something called "FixedMovie.mpg" or what-ever. Make sure you select to save ALL.


Womble will paste the two clips back together AND as a normal operation re-build the joined area plus and minus a few frames. You'll only loose two frames (or 15th of a second) and you'll never notice it. When checking, the new mpeg should be minus the number of frames you cut, when compared to the original.


Now demux this new mpeg and import it into DVD-Lab and do your normal authoring. Or if you want to double check .. do a short compile using the above technique just to make sure it will fully compile. (I'd recommend this for a troublesome Mpeg as you may have more than one problem frame area)


This worked every time I did it. And it should only take you 5 or 6 minutes tops once you have the process down.


An Alternative way:


Instead of making a 1st half and 2nd half with the in-between frame or two not included, you could just mark the last known good frame as the BEGINNING mark, and then move a couple frames to the right and mark that frame as the ENDING mark and simply CUT that section out. This as opposed to saving two segments to be later re-joined. HOWEVER, as I've mentioned many times, doing a "cut" out of video often produces problems with sync. I think Womble does a better job joining two segments from scratch than cutting and joining all at once, if you know what I mean.


Gotchas


I've found that most of the time the problem frame(s) is during a fast cut from a slow scene to a fast scene. Especially if it's like a "talking head" AND they "merge" right to a high action scene. I believe the ReplayTV mpeg encoder starts with a very low bit rate (the little movement talking head scene) and then has to change quickly to a very high bit rate (the action scene) and IF there is some kind of transition between the two, the encoder screws up the GOPS, bit rate and who knows what else? And it's almost impossible to find, even when viewing frame by frame. It has to do with "motion estimation" and is very hard to do "real time" at 30 FPS. This is why "real" DVD mpegs are done with multi-pass non-real time encoding. Each pass fine tunes the mpeg more precisely. The poor ReplayTV encoder doesn't have that luxury and has to do it's encoding "real time", in one pass.


Another common problem is more viewable. This is where the encoder looses it's video signal for a split second. The result might be one or more frames with "blocks" or generally messed up video. You CAN see this when stepping one frame at a time. I've seen that when this happens, it usually is for at least 2 frames and sometimes several.


Most of the time, just cutting one or two of the frames immediately after the last known good frame is enough. But sometimes you might have to cut more.


I've also forced Womble to do a re-encode of the bad area by INSERTING a special effect there. (only good if it's right at a scene change) This is the fastest and easiest and doesn't require ANY cutting etc. Just hit the insert trans. arrow and do it.


You will find the "problem" frame to be either visually damaged OR look perfectly normal. In the latter case, it's the GOP sequences and bit rate etc that are all screwed up and you would never know it. The Womble GOP fixer only fixes header information and GOP things as such and I don't think it "rebuilds" the video at the GOP level at all.


And in the aforementioned case of actual viewable bogus frames, using the DVD-Lab compile technique can find them a lot faster than if you were scrubbing through a hour's worth of video frame by frame.


This isn't a solution for every known problem with the ReplayTV mpegs. But I think it will show you a fast and easy way to eliminate at least a couple of them that have not been really discussed here.


Womble with it's GOP fixer can fix most of the "non-video" problems. It's great frame accuracy will allow you to get around video problems. If your problem is simply bad header information then DVD-Patcher can help there. And you can use this "hidden" feature of DVD-Lab to at least find the rest of the hard to find problems.


Lastly ... There CAN by operating system specific problems and/or parameters that can make working with mpegs difficult. There HAVE been a few guys who have had NO success at all, until they re-installed their operating system. This is NOT common but can be an issue. I would only recommend this if you found that someone ELSE was able to use your mpegs and you couldn't (using the same software and techniques of course)


Good luck ..

 

[whirly]

I've got one for the Guru ...


I have only one file that I can cut any of the frames out of a 4K MPEG EXCEPT the last frame and it saves just fine. If I cut that last frame out then Womble will just error out on the save and close the program. Drove me knutz until I went back and did incremental cut/saves ... they all worked just fine until I cut that last frame out then on the save ... WHAMO Womble choked and quit.


Have you seen this before and is there a way to get that last frame? I can live with it the way it is but it's one of those niggly things hanging out there.

 

[Sturmie]

thanks again Rich for all ur hard work....i should have the Fiesta Bowl done in no time now .


sturmie

 

[Rich A]

For Whirly,


Ah a challenge .. I love a challenge. heh heh


The first thing I'd have to ask is "how" are you cutting the frame? I've never had a problem cutting the last frame. Try it this way. Let's say your mpeg is 100 frames long. Scrub to frame # 99. Mark that as the OUT mark. Then copy that (0-99 frame) video segment to the clip list.


Then close the working mpeg window and drag the clip back onto the work area. Now save that. It could be the way you are cutting. I've said it a million times, Womble has trouble when you use the "cut" scissors to cut out a portion of a video (sometimes) But it will always work if you work with "saved" clips from the clip list. That would be the first thing I'd try.


My second thought. One of the problems that is surprisingly common to the ReplayTV mpegs is that the last frame will sometimes be missing it's audio component.


I noticed this when doing my authoring with SpruceUp. If using elementary streams (which is the best way to do it) during the SpruceUp compile at the very END, it would error and report that the last frame was missing it's audio. It would then ask if you wished to continue and discard the last video frame. So I would say, "yes" and all would compile fine. Now if you DON'T use elementary video and audio streams THEN you'd get the situation where SpruceUp would just plain die at 99 percent. (another reason to use separate video and audio for assets)


Maybe the problem you are having is something along those lines. I'd first have to ask if you are using the latest version of Womble. Some earlier builds had problems in this area.


What you might try is this.


De-multiplex the program stream Then load just the video stream into Womble. Cut the last frame there. Then save that as a new elementary stream. MyMovie2.mpv. The multiplex the MyMovie2.mpv with the MyMovie.mpa and see what happens. I'm betting the result will be your video with only the last frame missing. Never did that so don't really know. Try it and see. I figure Womble will either throw away the extra audio frame or add another video frame (which probably won't help anything) I'd be curious to see how it goes.

 

[jingcha]

Rich, thanks a lot again.

Same very basic ( ignorant) questions?


1.Should we always Demux a RTV MPEG before authoring with either Spruceup or DVD MF or DVD Lab?


2. Does it make a lot of difference if I import my RTV MPEGS straight to any of these programs without demuxing, if I find the MPEG file as a clean file after basic Commercials editing with Womble?


3. What exactly does Demuxing do?

and wait for one more and please don't laugh....... and pardon my ignorance ,


4.what exactly is Demux and multiplex mean in video editing ?


Jingcha

 

[whirly]

Thanks for the reply, I'll try that.


I always use the scissors to just clip out the commercials then save the resultant file. It has worked well on several hundred RTV4040 files but occassionally it doesn't.


I'm using v3.14 which should be the latest version.


I do always use elemental streams to author but I edit and save the .mpg files then demux.

 

[Jeff D]

Man people want to know these things? This seemed like common sense...


I would have posted something like this a while ago if I thought it was needed. Sorry.


I do the cut bad frames too, but slightly differently. There were many times in a show that runs on HBO with mobsters that has scenes that blow the bitrate sky high. I've been using bitrateviewer to get the bad frame (usually a frame with bitrate at 13kbps) and cut them out just like Rich described.


Good job rich, nice find of using DVDLab to do this! =)


Just one thing to note to any folks looking to us replay captured movies with this method... this is bad for IVTC steps when converting back to 24fps.... try to avoid this if possible.




jingcha, mux or multiplex and demux or demultiplex are how you split/join elementary streams (audio and video). Some common extensions mentioned above MPV mpeg-video, MPA mpeg-audio and m2a is another common one for mpeg2-audio.


An MPEG file is comprised of many different streams, Audio, Video, subtitle (different than CC), etc. You split streams out with a demux, and join with a mux. These steps are needed when you want to work with individual streams or to join streams back into a whole mpeg file.

 

[Rich A]

Quote:

Originally posted by jingcha Rich, thanks a lot again. Same very basic ( ignorant) questions? 1.Should we always Demux a RTV MPEG before authoring with either Spruceup or DVD MF or DVD Lab? 2. Does it make a lot of difference if I import my RTV MPEGS straight to any of these programs without demuxing, if I find the MPEG file as a clean file after basic Commercials editing with Womble? 3. What exactly does Demuxing do? and wait for one more and please don't laugh....... and pardon my ignorance , 4.what exactly is Demux and multiplex mean in video editing ? Jingcha

Not ignorant at all. I always felt there’s a difference between being “ignorant†and simply “un-informedâ€. I'll start with the "Muxing" question first.


3. What exactly does Demuxing do?


Mpeg video is comprised of 2 or more streams. When these individual streams exist separately by themselves, they are called "Elementary streams". The main elementary streams we are interested in are the video and audio streams. These are “merged†during the time of encoding into one single stream that we call a “Program Streamâ€. This “merging†process is called “Multiplexingâ€. If you take an already multiplexed (merged) program stream and separate the video from the audio to create it’s original elementary streams it is called “De-multiplexingâ€. “Muxing†and “DeMuxing†are just shorthand or slang terms for Multiplexing or De-multiplexing. Note that it is actually more accurate to refer to this process as “merging†than “joiningâ€. Joining is technically the term to use when you concatenate two items. For example adding one mpeg to the end of another, or splitting an mpeg and inserting another mpeg in between the splits. Muxing, is actually taking two or more streams and “merging†them from their beginning to their ends, keeping their elements (the video and audio) in proper sync.

There are other types of “merged†streams that are different from Program Streams. A “system stream†is one variation. The difference is that the system stream is put together with different parameters to be used in a different environment. To over-simplify it the program streams we are using are for viewing. The “system stream†could be for “streaming†which could be used to playback via a transfer over the web. Or providing real time video across phone or office intranets or LANS.


More than you wanted to know:


While program streams are comprised of Multiplexed (merged) Video and Audio elementary streams, there can sometimes be other less common streams included. Real time mpeg encoders sometimes use a "padding stream" to keep the video and audio in sync when the timing gets a little off. BTW, this was one of the problems with the earlier versions of Womble and still so with some other editors. For example the ATI All In Wonder video capture card does it's real time Mpeg encoding totally in software. And if the CPU or system in general can't keep up or the sound card timing isn’t accurate enough, it will add a padding stream just to keep the video in sync with the audio. In fact the padding stream is always there, just used more with some systems or if not needed it just adds nulls. The result (back in the early days) was that during a Womble de-multiplex, Womble would take this third stream and ignore it. It didn't know what to do with it. THEN when you multiplexed those video and audio streams back together, because the padding stream was now missing, the audio would become out of sync. I've often referred to this as PESS, or Post Edit Sync Syndrome. Where your video would play perfectly BEFORE editing and then out of sync AFTER editing. We worked with the head programmer at Womble, (a great guy by the way) and he adjusted Womble to take this padding stream into account. The result was no more trouble. Interesting to note, was that while many of my friends had this "PESS" problem with their ATI cards, I did not. Yes the padding stream WAS in my ATI Mpegs. BUT, my system was good enough in all aspects to not need it and therefore the padding was null and if it was removed it did not cause any problems. Simply put, zero from X is still X. I don’t know if the problem was a “non-standard†implementation of this padding stream or earlier versions of Womble just not recognizing it. I should note that after Womble was changed the problem went away for many. AND about a year down the road, ATI changed the encoding so this problem no longer even affected the older versions of Womble and other editors.


1.Should we always Demux a RTV MPEG before authoring with either Spruceup or DVD MF or DVD Lab?


When you author a DVD you are adding play lists and menus, and buttons and effects. In addition to those things “you†create, the DVD authoring program also has to take your mpegs and “re-build†them into VOBs. These VOBs are basically Mpeg video that has been Multiplexed with intrinsic parameters that are suitable for playback on a DVD disc. You can’t create a true DVD by just copying the mpeg to a DVD disc. Although with some of the newer DVD players, you CAN do that and manually play back the video okay. But for a real properly authored DVD, you have to have software that will take a video and audio stream and multiplex them into an mpeg stream that is suitable for use within the DVD environment.

Now .. IF you supply your DVD authoring software with a fully multiplexed program stream, THEN the DVD software has to first DE-multiplex it into elementary streams. Now remember earlier when I was referring to some encoders adding more than just video and audio streams during their mpeg multiplexing? Sometimes the DVD authoring software can have trouble with the elementary streams it created because of these additional streams. Supplying full program streams also creates a 2nd step you really don’t need. That is you import that single Mpeg Program stream as a DVD movie asset and then the software has to De-multiplex it into elementary streams anyway. Then when it does it’s “compile†it has to Multiplex those video and audio streams back into a program stream (the VOB) suitable for optical disc burning.

So if you supply the authoring software with the already de-multiplexed stream (ie a separate video and audio stream) then the DVD software doesn’t have to do any DE-multiplexing. This has two advantages. First using a program editor or other utility made for de-multiplexing is usually faster than using the built in de-muxing of the authoring software. Second, there is less chance for any “odd-ball†extra things in the full Mpeg program stream to give the DVD software trouble because all you are giving it is video and audio with most of those “odd-ballâ€, non-standard things removed. While most DVD authoring software will properly de-mux your full program stream, there is a chance it could choke on some. Rare but it happens. If you use elementary streams that chance is reduced to almost none.


2. Does it make a lot of difference if I import my RTV MPEGS straight to any of these programs without demuxing, if I find the MPEG file as a clean file after basic Commercials editing with Womble?


Some of the things inside an mpeg are what I would call “intrinsic†parameters. These are things that exist but are normally not viewable or editable by the user. Things like the “multiplexing RATE†and “Pack sizes†are examples to name a couple. Although the program stream may LOOK fine to you, it’s really a roll of the dice when you import it as a DVD asset. As mentioned above, it wouldn’t make any difference in maybe 9 out of 10 sessions. But IF you have a problem with just one, after doing all the DVD authoring then you may have to start from scratch all over. I’d rather use the elementary streams always. And instead of a problem say every 10th use, I end up with one problem every 100th use (or less). If you KNOW your encoded mpeg is 100 percent proper then it really doesn’t make a difference. Other than it speeding up the DVD authoring process by not having it do the de-multiplexing.

Another “by-product†and advantage to supplying video and audio elementary streams comes into play when you use SpruceUp. You can have your DVD software “choke†at two points. First during the asset IMPORT. Or secondly during the software muxing of the VOB files (creation of the title set) If you supply SpruceUp with elementary streams and there is a serious enough problem during the ASSET IMPORTING, it will give you the GOP number where the problem occurred. This helps to troubleshoot the problem. If you had given it a full program stream, then it just gives you a percentage figure where it bombed out. Which is not very accurate.


More stuff you didn’t want to know:


During ENCODING the video is being captured and the audio is also being captured. Part of what the encoder does, is to multiplex them into a program stream. So your “muxing†is really an intrinsic part of the encoding procedure. During this “muxing†which is done along with the capturing in real time with the RPTV encoder, some important intrinsic values are used. For example the Muxing rate and Pack size are are very important. Pack sizes used are DIFFERENT for DVD than say (S)VCD.

This is one of the reasons you have to do a full re-encode of the Mpegs from the RPTV when you want to use them as say VCD sources. Not only are the frame sizes incorrect, and the audio incorrect, but the pack sizes created during the capture/multiplexing are also different. (as well as some other internal parameters)

Hope this helps …


Important added edit:


After re-reading this (I kinda wrote it "on the fly") I'd like to say that where I refer to "multiplexing" during the creation of the VOB files may not be exactly correct. While the VOBs are created FROM the original Mpeg, I'm not so sure there is any "multiplexing" going on in some cases. I suppose there IS if the program only had elementary streams to work with. BUT as was pointed out by someone recently, Oscar's newest DVD-Lab will now take an mpeg program stream WITHOUT having to de-mux it. I can only assume that if that is the case, then the program stream would be used "as is" for creation of the VOBs without any muxing involved. BTW one of the things the VOB creation does is to split up the mpeg into chunks that will keep each at 1 GB or less.


I'm of the opinion that the "no demuxing" option in the latest DVD-Lab version is going to create more trouble than not. This because the program will no longer have the "control" over the mpeg format during a multplex process. So we will probably see more people with errors that don't show up until the VOB creation OR worse .. during playback of the finished DVD.

 

[tluxon]

This is a wealth of information that I was waiting to see brought into a single thread like this. However, all of this information refers to making a DVD. Will it address any problems in making SVCD's or is it totally irrelevent since SVCDs are re-encoded?


Will it address audio synch problems? I'm getting some strange audio synch problems when joining commercial-free clips of longer programs. For example, I was starting to clean up the movie, "Holiday in the Sun" for my kids, and saved each segment (between commercial groups) to a separate file. I noticed that most of the segments had no audio synch problems at all, while a few we off by a couple hundred milliseconds (guess). Can these synch problems be addressed using your method on the individual segments?


Thanks,


Tim

 

[Jeff D]

Rich's technique here is for video frames only.


Audio sync is a different beast altogether. There are many factors for the sync issue.


Your technique for creating a SVCD may need to change a bit.


I'm confused by one point, are your segements put back together for the vcd creation?


Here's how I'd do it...


Using womble, good for keeping sync when editing.


Use Rich's technique (kudos to rich for his original description):

mark start and end frames copy segment to clipboard.

repeat for all program segements.

Close source window.

Drag clip on into workspace this opens up your active edit window.

Use the arrow in the far righ group (brown color?) that looks like backwards L with an arrow at the top. (Move to end)

drag clip two into the active edit window.

The merge dialog comes up, I always click on ok without selecting anything special.

click on the up right arrow to move to the end.

repeat this drag/drop, merge choice, move to end segement (last 3 steps) until all clips are entered.


Save the clip.


Use the new clip with tmpgenc to re-encode for SVCD.


Another option that may work is low quality (standard) recording. Rich is this format a valid SVCD format? I don't remember off the top of my head. If so you could skip the reencode step.


The key here is that the audio "should" be fine when you go to the re-encode stage.


When dealing with segmented clips you run into all sorts of gotchas with audio data. Missing audio chunks and such will screw with the final clip. You want as close to a good clip to start with. =) Womble technique is the best way I know.

 

[flicker]

tluxon,


I have been creating SVCDs using medium quality files from my 5080 for a while now. I've been able to do this without buying womble. I use a combination of DVD2AVI (free program) and TMPGEnc Plus (free trial, then $48).


I've posted on this forum in the past how I do it (it's real easy, and with no audio synch problems). I haven't posted that much, so if you look at my posting history you will easily find it.


Good luck!

 

[Jeff D]

Oh DVD2AVI and avisynth is another option to feed into tmpgenc... that would work well to.


Take DVD2AVI and open replay file.

Save project (f4) save it as whatever

this creates audio and video files video will be called whatever.d2v.


You can create a avisynth script that opens this file. Go into virutaldub and open the avisynth file find frame numbers of the clips you want to edit out. Use avisynth trim to cut those segements out.


The only thing I'm unsure about is using the audio file in the avisynth script.


Things you'll need....

avisynth v1.76 (only this version don't try newer versions)

mpeg2dec3.dll (avisynth plugin)

virtualdub (any version)

tmpegenc (need the encoder)


simple avisynth script...
Code:

LoadPlugin ("mpeg2dec3.dll")

video = MPEG2Source("whatever.d2v")
audio = WavSource("whatever.wav") # the file will be different name...

# combine them into a single clip
av=AudioDub(video, audio)

#trim points will come from virtualdub when looking through the clip note the frame numbers. Trim works Trim(clip, firstframe, lastframe)
s1=trim(av, 100, 2040)
s2=trim(av, 3499, 5034)
s3=trim(av, 7785, 9235)

out=s1++s2++s3

 

[smckean]

Quote:

Not ignorant at all. I always felt there’s a difference between being “ignorant†and simply “un-informedâ€. I'll start with the "Muxing" question first.

Rich A -- I am relatively new to the world of A/V (but not to RTV's). I am learning about DVD's etc. I have spent weeks searching the internet and reading stuff to educate myself. Much remains confusing, but I knew enough to know what I didn't know


I could not find answers to my wonderings. Then your msg here turned up. It is simply the best I've seen anywhere. FINALLY I understand. I don't know where one can find info like this elsewhere (and *certainly* not so well presented).


THANK YOU

 

[tluxon]

Jeff D,

Thanks for your reply. I used to always merge my segments into a single file just as you described. The audio sync problems exist in the same places whether segments or a single file. The advantage to segments is that they are handled as skip points when my DVD player plays the CD-R(W) that I've recorded them to (unfortunately, my DVD player doesn't allow direct access to any time point on (S)VCDs). Also, since the sync is different in various segments, if I somehow need to "shift" the audio with respect to the video, I can treat each segment according to it's offset (believe it or not, it's not linear as you go thru the movie).


As for re-encoding, I've used TMPGEnc (really like the KVCD templates), but prefer to use 4-pass VBR using Avisynth in Cinema Craft Encoder. I just don't want to spend hours re-encoding if my video and audio aren't in sync .


flicker,


You say you haven't had any audio-sync problems using your method? I almost tried your method a couple months back, but that was just before I started having fun with Avisynth and CCE. DVD2AVI's project files are very useful, so I'll have to give it another shot pretty soon. I do remember that I often had to do a "fix-time" on the file for DVD2AVI to not choke on it, however.


Thanks,


Tim

 

[flicker]

first, apologies to Rich A -- sorry for turning this thread into a SVCD chat. (p.s. I love reading your posts)



But, since we now are on the subject of SVCD .....


tluxon,

That is correct. I've made probably a dozen SVCDs so far using just DVD2AVI and TMPGEnc, and I've never had a problem with DVD2AVI being able to open my ReplayTV files. Also, my audio sync has always been dead on (knock on wood). The file name of the audio file coming out of DVD2AVI has the number of milliseconds that the audio is off for that particular clip, and you enter that into TMPEnc before starting the encode-to-svcd process.


And now an SVCD question to all:

While TMPGEnc is doing it's thing and encoding SVCD for me, it makes no difference if I let it run in the background and use my computer for other things, right? I understand that taking processing power away from it for other things will extend the total encoding time, but that's ok. I just want to confirm that it has no effect on the final quality of the SVCD.


My 866MHz P3 takes quite a while to encode a show. That's fine with me, as long as I can use my computer in the meantime. I just hope that don't get advice to "leave it alone" while encoding to get the best quality result.


Thanks everybody!


flicker

 

[Will Collier]

Quote:

Originally posted by Jeff D I do the cut bad frames too, but slightly differently. There were many times in a show that runs on HBO with mobsters that has scenes that blow the bitrate sky high. I've been using bitrateviewer to get the bad frame (usually a frame with bitrate at 13kbps) and cut them out just like Rich described.

Jeff, a "Duh" question... where in bitrateviewer can you find the exact frame number of a bad frame? All I can see displayed is a time (only accurate to the second), and a total frame count. TIA...

 

[Jeff D]

Sorry Will, I've using a bit of my super powers.... I get the time to a second, there are 15 frames in there that I step through, I know enough about MPEG to figure out which frame is bad. The bad frames are USUALLY during a transition frame (ie scene change)


I may have also used a tool by the people that make the elcard codec. I bleieve you can look at frame bitrates. So take bitrate viewer get a time frame second. From there take the clip into the elcard tool (sorry, I can't remember the name and I'm too lazy to search.) But, with that tool you can display I,P and B frames in a bar graph form you can get a frame number that way, (It's been a while, but I believe that's how I did it) This tool also pointed out some P and B frames that went sky high, I was never sure if these were "errors" in the app.

 

[Jeff D]

MMSExplorer is the app and Mpeg Stream Explorer, something about Moonlight too.


Anyway you can filter on specific frame types. The only bad thing... only works with the elcard codec, which I try to keep uninstalled. I hate the tic-tac-toe box on playback. I'm not smart enought to configure my system to only use that codec as a last resort...

 

[lizard_boy]

I can see 1 frame, probably because I worked as an editor for a few years. Makes it hard to watch anything 'normally' without thinking about the editing decisions that were made. For any network-asshats reading this I often find myself going back to repeatedly watch commercials that I find interesting from an editing or production standpoint


Having said that I often used this technique to remove problem frames in video or film. Sometimes I would repeat either the frame before or after the problem frame so the audio wouldn't have to be tweaked, I would also reduce a bad frame to each of its fields (since video is interlaced each frame has 2 fields) and could then replace the bad frame with whichever field looked better.


With most video/film you will only notice a slight 'jump' if you're watching very closely - 99% of viewers probably wouldn't notice a thing, especially since the jump could be caused by any number of problems in delivering the video from its broadcast point to the viewer's home. It's very similar to the jump you can see in sporting events right before the network goes to the info bar at the bottom of the screen. A few of my dumber friends are always impressed when I'll hum the CBS NFL update jingle right before they play it.


I'm always amazed that I still catch a few "flash frames" every year in network TV shows, with the amount of eyes that see these shows before they go on the air you'd think someone would have caught them before they aired.

 

[Jeff D]

I have to agree with Lizard and I'm sure Rich will agree too.


One frame really IS something you do notice, but.... and here's the good thing, only if you are informed and trained to notice this crap. Ignorance really is the best way to proceed.


Once you know the flaws you see them everywhere. MPEG artifacts, continuity errors, dropped frames, miscolored section of the screen for one field, nipple flashes (like Tawni Katain in Whitesnake "Here I go Again" video. I was like 16 and saw it once ((I was taping for some REASON)). after that... edited out), you name it you see it... bugs the crap out of me.


The cool thing.... my wife is now catching stuff. She's seeing more, that's always good. She'll ask "did you see that?", I have to respond with something like... "the cup that changed color or the guy who dropped out of character and laughed for no reason?" =)