Note: Version 1.0.1.5 is now available (02-15-07).

Please download the attached file or visit:

http://homepages.roadrunner.com/mwilczyn/mpeg2


What's new:

1.0.1.5 / 02-15-07:

• Added "bad-edit" detection to show inconsistent telecine flags. Use "IgnoreFieldRepeatFlagWarnings" ini setting to disable.
• Added "ReadBufferSize" and "WriteBufferSize" ini settings. Might improve file i/o performance if you're not CPU limited.
• Improved performance of initial PID scan on slow wireless networks.
• Added "FileWildcard" ini setting to allow custom input/output file extensions.
• Added limited H.264 video support. Only scans for Transport/PES header errors.
• Removed beta expiration date. Barring any major bugs, this is the final version of MPEG2Repair. Moving on to other projects...



Hello,

I'm pleased to announce the public release of my new Mpeg2 error detection/repair program called "MPEG2Repair". It's designed for testing and repair of HDTV transport streams. Features:

-Error Detection:

Find file errors resulting from signal drop-outs, faulty tapes, encoding errors, etc. Detection code checks transport layer for continuity errors and faulty headers. Code also checks the MPEG2 PES layer for parsing errors (corrupted macroblocks, slices, headers, etc.). All errors are logged with time stamps and file positions so you can easily locate them inside your original recording. Very useful for verifying files prior to permanent archiving.

-Error Repair:

Automatically repair minor Mpeg2 transport and PES errors which may cause problems for certain decoders. Tool will remove erroneous data from the file by either cutting it out or replacing it with valid bits. The goal of repair is to create a fully Mpeg2 compliant file that will not crash, hang, or stall decoders which were not designed to deal with errors. Repair is currently not intended to improve the visual appearance of errors but simply to remove them.

-Improved Decoder Compatibility:

Automatically fix other issues that may affect decoder compatibility. These include partial GOP's, missing headers, incorrect continuity, etc. This feature is especially useful for those of you with old recordings from the 169time system. They should now play smoothly on other decoders besides the JVC 30K deck.

Mark, GREAT STUFF!!

Dave

Thanks for all the email feedback so far. There's definitely a reason I called this an alpha (vs. beta). I know there are lots of bugs yet to be fixed. I figured I would release it anyway since many people seemed interested and it works perfectly for my setup (Dish 6000/169time Hard Drive recording). I never would have found the remaining issues/bugs without getting other people to try it.

To answer a couple of the emails:

1) It's been reported that some virus checkers think there may be a virus in this program. That's a false alarm. The program is packed to produce a smaller exe file. This seems to confuse some virus checkers.

2) Program was compiled with Visual C++ 7.1. If you've never installed any other software that uses that version, you may need some additional DLL files. Here's links to what you need (just unzip them to the same directory as Mpeg2Repair):

mfc71.dll : http://www.dll-files.com/dllindex/dll-files.shtml?mfc71
msvcr71.dll: http://www.dll-files.com/dllindex/dll-files.shtml?msvcr71

3) The repair feature is intended for minor corruption that causes compatibility problems. It will not fix a recording which is so corrupted that nothing will play it at all. If you have access to a JVC 30K DVHS unit, try playing the original on that. The JVC decoder is very good at dealing with errors. If it can't play your file, it's unlikely that I can do anything to fix it.

4) A large number of continuity errors means that you're losing data somewhere during recording. It could be between the satellite/STB, STB/recorder, or recorder/pc. In any event, large amounts of continuity errors are usually beyond repair. You will need to check your hardware to fix the source of the drop-outs. Also try testing the file with TSReader Lite to make sure the continuity errors are not a false alarm/bug in my program.

In addition to reporting bugs, please post any positive feedback as well. I'm curious if this is useful for anyone else but me. Especially people with Dish6000 recording HBO_HD/SHO_HD.

Thanks.

-Mark

Dumb question time.

Is this for repairing .tp files or .mpeg files? Ie. Transport Stream or Mpeg2 files

I am asking because I ran it on a .tp file that was created from the HD-TIVO and the program crashed and only generated a 0 byte output file.

The I ran it on a .mpg file that was created from the HD-TIVO and the program crashed trying to find the PID's


Thanks

Originally posted by Joe Q
Dumb question time.

Is this for repairing .tp files or .mpeg files? Ie. Transport Stream or Mpeg2 files

I am asking because I ran it on a .tp file that was created from the HD-TIVO and the program crashed and only generated a 0 byte output file.

The I ran it on a .mpg file that was created from the HD-TIVO and the program crashed trying to find the PID's


Thanks

Transport Stream files (usually .ts,.tp suffix). It's possible that TIVO is using some proprietary format that I don't yet support. If you like, you can send me a sample (~10 MBytes) to mpeg2repair@adelphia.net. I'll take a look and let you know if I can add support in the future.

On a related note... people should hold off on using this for anything but Dish satellite recordings. I found an issue that affects OTA and possibly DirectTV that I need to address. I'll post a message here when a new version is available.

Just a quick status update...

I'm still working on the next release. I would discourage anyone who's downloaded the first version from using it. There's some serious issues there which make it next to useless for anything but unsplit files from HBO/SHO on Dish. Most other channels and split/segmented files will not work correctly.

The next version keeps getting pushed back as I add new features. I just found out that some OTA stations (like FOX here in LA) and TNT_HD (before Dish started recompressing it) use yet another non-standard format. I'm adding repair support for them now. Current ETA is this weekend.

-Mark

Thanks for the updates and your efforts.

New version now available (see first post in thread). I feel this version is stable enough for general public release. It should now be very reliable at finding errors and dealing with all the major formats. Repair seems good enough for 169time usage. Any other repairs should always be verified to make sure you like the results compared to the original.

Due to lack of time, this will likely be the last release for a while. I hope you find the program useful.

-Mark

I just made a small change (9:45 PM PST) to version 1.0.0.3. It shouldn't affect anything but you may want to download again.

Also, you may be interested in the NullPacketSaver program that's also on the site. It's an alternative to the various null packet removal tools out there (NullPacketStripper, etc.). This one also removes null packets but offers the option to put them back later if needed.

-Mark

Thanks a lot Mark for this great software. I've got some recordings that I couldn't read with my system (MyHD) because it was recorded on some other systems. After having them being processed with your software it works just fine.

I have processed 10 movies so far without any problem.

J.

Mark,
Another thanks for providing such an excellent tool. I've noticed that even the most stable AVX-1 software revision (08D6) gives streams with occasional corrupted bytes in the MPEG video. I now run every AVX-1 recording through MPEG2Repair before it is transferred to D-VHS. The resulting streams play fine on all of my hardware decoders (MyHD, LG 3410A, Samsung SIRT-165, RCA DTC-169, and JVC 30k). Nice work.

-Dylan

Originally posted by dahester
I now run every AVX-1 recording through MPEG2Repair before it is transferred to D-VHS. The resulting streams play fine on all of my hardware decoders (MyHD, LG 3410A, Samsung SIRT-165, RCA DTC-169, and JVC 30k).Dylan: are you using any of the newer AVX1 software releases, like 08D6? Or are you referring to older AVX1 recordings?

169Time has claimed that the new AVX1 software produces recordings that are compatible with a wider variety of decoders than before. But is it in fact necessary to process even newer streams with MPEG2Repair in order to get decoder compatibility?

Ron,
Yes, you should run MPEG2Repair on all your AVX-1 recordings.

I'm using 08D6 with a Dish 6000. I still get the same types of errors as with older software versions, just fewer of them. I've gathered statistics from MPEG2Repair's error log. Older versions of AVX-1 software (pre-08C6) typically have 1 bad frame per 1000. With 08D6, I'm getting 1 bad frame per 10000. Now, bear in mind that I generally start with recordings that have ZERO continuity errors. Recordings with ZERO continuity errors have perfect audio but the MPEG video still has corrupted bytes as an artifact of the AVX-1 software, which are neatly fixed by MPEG2Repair.

I've been on the warpath to banish dropouts, glitches, etc. and MPEG2Repair has been a godsend. I have a pretty strict flow which does not allow much junk to get past me. First I capture everything to the hard drive. I run ec.exe to check for continuity errors. This program can scan a 2 hour movie in 6 to 10 minutes to tell you if you've got errors. I usually split my recording into many files so I can isolate the files which have the errors, watch them in MyHD, and determine their severity. If there are several glitches I often throw out the recording and re-capture it on a later broadcast.

Otherwise I run it through MPEG2Repair and check the error log. Once again, if the error log is suspiciously verbose, I check it out in MyHD to see if the 'fixed' glitches are still severe. After passing the two tests, I transfer the recording to D-VHS and/or archive to DVD-R. Because of all the steps I take, I make fewer recordings now than I used to, but each one I keep is virtually perfect.

If you really want to know how good a capture you have made, you should run your recording through ec.exe to check continuity errors (sound), and then MPEG2Repair (video), and inspect the error logs.

-Dylan

Well, that's good news. I hadn't expected that (in particular) older AVX1 streams would be reparable.

It's clearly a labor-intensive process, though.

Have you tried MPEG2Repair on streams originally recorded with the Panasonic TU-DST50 and DST51?

How about streams recorded with the R5000-HD? Are they affected in any way (bad or good) by processing with MPEG2Repair?

I have not tried MPEG2Repair on Panasonic recordings yet. Panny recordings are notorious for being difficult to work with. You can't null strip them without getting into trouble, mainly because the timestamps are really weird. If a program comes along and restamps the PCR, the resultant file will not play back smoothly in most hardware MPEG decoders.
I'm afraid MPEG2Repair might not work well with them.

I don't have an R5000-HD but may get one if they ever go on sale. It's hard to justify a $1000 outlay when the AVX-1 + CapDVHS gets the job done.

-Dylan

Originally posted by dahester
If you really want to know how good a capture you have made, you should run your recording through ec.exe to check continuity errors (sound), and then MPEG2Repair (video), and inspect the error logs.

-Dylan

Dylan


What and where is ec.exe?

Does it fix continuity errors, or, just scan and report them?


EDIT: I got a clue:

"Have you tried balazer's ec.exe utility? " Dylan

I think that the missing component in assigning blame for errors are the satellite transmission themselves.

Testing needs to be done to prove what only some people know.

The STB’s sold by E* & D* are very good at masking errors, particularly video errors.

While the JVC 30K is also very good, PCI cards like MyHD and software are less so.

Look at the response the R5000 folks are offering for some lost recordings. "Tests have shown that these were always associated with reception glitches and drop-outs."

For various reasons, many of the most active enthusiasts want to use other than D-VHS decks form JVC to playback their HD captures.

The fact remains that since the sat providers are squeezed for bandwidth they are pushing the limits with three channels on a single transponder with various retransmission wizardry and the quality and consistency of the transmissions are suffering for it.

You can see live glitches on SHOHD from E* and many other anecdotal reports of visible errors have occurred in the last 3-4 months.

Still, I do not know how you objectively test the source itself separately from the device used to capture the signal

Though not many of us can take advantage of them, the few Digicipher II C-band HD "master feeds" available to consumers (for HBO, Showtime, Starz, Encore, and Discovery) are probably the best sources to use for captures, since all other providers derive their feeds from these, re-encoding them and re-transmitting, and introducing errors in the process.

The 169Time-modified HDD-200 is currently the only way to record these that I know of, though Nextcom has said that they plan to provide a mod for use with the R5000-HD.

Originally posted by dahester
Ron,
Yes, you should run MPEG2Repair on all your AVX-1 recordings.

I'm using 08D6 with a Dish 6000. I still get the same types of errors as with older software versions, just fewer of them. I've gathered statistics from MPEG2Repair's error log. Older versions of AVX-1 software (pre-08C6) typically have 1 bad frame per 1000. With 08D6, I'm getting 1 bad frame per 10000. Now, bear in mind that I generally start with recordings that have ZERO continuity errors. Recordings with ZERO continuity errors have perfect audio but the MPEG video still has corrupted bytes as an artifact of the AVX-1 software, which are neatly fixed by MPEG2Repair.

-Dylan

Dylan

I happened to have asked Richard at 169Time about MPEG repair utilities in general, and, he wrote me back as follows:

“If a user records and plays on the deck, the deck's built in decoders are robust enough to polish the signal.

When a software based decoder is used that is not error tolerant, a pre-process utility can be applied to mask these errors so they do not cause the decoder to seriously malfunction. That is the function of this software utility being touted here. It masks errors but does not correct them.

A more robust software decoder could also include a masking process and not require this separate step. The pre-playback error masking utility duplicates some of the processing that a software decoder does, and thus it is more logical that the error masking be done by the software decoder at playback time rather than as a separate pass utility, put that on the decoder wish list.

Some hardware based decoders also benefit from this type of pre-playback error masking process.

A robust decoder masks errors in real time at playback as part of the decoding process. Error masking could also become part of the real time process when files are recorded from the transmission. That is the next step toward perfection, but it duplicates some of the process that is typically done for playback decoding.

Bottom line- Even without error masking, the 169time system is making recordings that are equal in quality to the received signal”

Richard at 169Time - support@169time.com

I agree that MPEG2Repair isn't correcting the errors per se. Corrupted data is forever lost, but the utility does mask errors to sensitive MPEG decoders very effectively.

I disagree that the 169time system is making recordings that equal the source. I have been lucky enough to make simultaneous recordings of the same channel from the Dish 6000 and a cable box (my cable provider doesn't have its CP flags straight on all channels yet). I have run MPEG2Repair on both and found the cable recordings to have no errors, while the AVX-1 still exhibits errors. Now, I can't rule out the possibility that E* is introducing errors into the stream. But this data makes me suspicious of the AVX-1, especially in light of its history.

BTW reception problems are typically characterized by corrupted video AND audio through lost packets. In all software versions of the AVX-1 that I've tried, when the recording is free of lost packets the audio is perfect, but I still see video errors caught by MPEG2Repair. I have not seen this characterisitic in any other source I've recorded.

-Dylan

Originally posted by dahester
I agree that MPEG2Repair isn't correcting the errors per se. Corrupted data is forever lost, but the utility does mask errors to sensitive MPEG decoders very effectively.

I disagree that the 169time system is making recordings that equal the source. I have been lucky enough to make simultaneous recordings of the same channel from the Dish 6000 and a cable box (my cable provider doesn't have its CP flags straight on all channels yet). I have run MPEG2Repair on both and found the cable recordings to have no errors, while the AVX-1 still exhibits errors. Now, I can't rule out the possibility that E* is introducing errors into the stream. But this data makes me suspicious of the AVX-1, especially in light of its history.

BTW reception problems are typically characterized by corrupted video AND audio through lost packets. In all software versions of the AVX-1 that I've tried, when the recording is free of lost packets the audio is perfect, but I still see video errors caught by MPEG2Repair. I have not seen this characterisitic in any other source I've recorded.

-Dylan

Dylan

I believe your suspicions that the 169Time AVX1 software ADDS errors may be more speculation than fact.

Your post peaked my interest and Richard responded to it as follows:

"Audio and video packets are transmitted separately in time and a video error is 40 times more likely to occur due to the data rates. Errors could also be introduced by Dish's processing. Using the 40X rate and his previously stated error rate of once per 10000 frame (not verified by me), an audio error would occur once in 400,000 frames approximately, or about 4 hours."

"(AVX1 software) Version 08C6 removed all the issues that contributed to stream errors. The only stream errors coming out now are the ones coming in from the satellite receiver."

"Where the goal is to archive at the highest quality, even the results of the repair utility need to be verified since it is a mask routine and not a correction"

It is impossible and really unfair to state unequivocally that the AVX1 software is not a faithful recording that is "equal to the received signal".

You might want to email Richard at support@169time.com to better advance your process.

Murray, thanks for serving as messenger here.

Let me take a different angle on this. I have numerous sources of HD which I have recorded and analyzed: Dish (with AVX-1), cable, OTA, free-to-air satellite, and a considerable library of recordings made with the sorely missed Dish 5000 and modulator. I have considerable experience ripping apart these streams and reconstructing perfect copies by editting the best parts of duplicate copies of a movie in Hi-Def, and re-encoding to produce a perfect version.

The AVX-1 is the only source I've encountered which shows the characteristic that video bytes are corrupted while audio bytes are preserved with no continuity errors appearing in the stream. This has been a hallmark of AVX-1 recordings since day one.

Having said that, perhaps Richard has removed one source of error (i.e. software) only to reveal another source of error which occurs less frequently (i.e. hardware). There are no fewer than four Firewire devices which are needed to make recordings from the AVX-1 to a Windows PC (three is the bare minimum but practically speaking you also need a JVC deck to be able to monitor the AVX-1 output). There is a non-zero probablility that corrupted bytes will occur over Firewire since the data is carried over an isochronous channel, which provides guaranteed bandwidth at the expense of error-free data delivery.

There was a time when I had both a Dish 5000 + modulator and a Dish 6000. At this time unequivocal comparisons could be made between the two systems. Recordings I made with both systems show that the Dish 5000/MyHD recordings are perfect as reported by MPEG2Repair; the AVX-1 recordings, even with no continuity errors, require extensive repairs to the MPEG video while the audio is perfect.

It is possible to show unequivocally whether or not the AVX-1 software is a faithful recording that is 'equal to the received signal.' I propose that someone use an R5000-HD and an AVX-1 system to record the same material. An analysis in MPEG2Repair of the two recordings will verify what I am postulating.

-Dylan

Hi guys,

Glad to see there is some interest in my program. :)

I'm not sure if I can go into much detail regarding 169time errors because I signed an NDA with them while helping to debug their new software. But I can explain the mpeg2repair error logs in more detail so maybe you can reach your own conclusions.

Most errors are accompanied by an MBA (Macroblock address) and/or Slice number. An mpeg2 picture is made up of 16x16 pixel squares called macroblocks. Macroblocks are then grouped into horizontal strips/slices that cover a single row of the picture. For satellite, there seems to always be a single slice per macroblock row, but for OTA you often have 2-3 slices per row. To give some real-world examples, here's how things look for a typical 1920x1080i Dish satellite file:

1) Picture is made of 68 slices. Slice number 1 is follow by slice 2 below it, etc. Each horizontal slice contains 120 Macroblocks of 16x16 pixels each for a total of 1920x16 pixels. If you add up the slices, you will see they cover 1920x1088 total pixels. Because the macroblocks must be a multiple of 16 pixels, there is an unused 8 pixels at the bottom of the picture. On some players, it's visible as a small gray border at the bottom of the image.

2) To convert an MBA address to a pixel location, use this formula:

x = 16*(MBA%120); - here '%' stands for mod operator (remainder of a division)
y = 16*(MBA/120); - here you divide and drop the remainder.

For example, MBA=8155, would mean you have an error in a 16x16 macroblock where the top/left pixel is at 1840,1072. Maybe you can find something interesting by looking at the picture locations of 169time errors. ;)


When my tool repairs a file, it basically plays the entire file just like a software mpeg2 decoder would. This allows it to catch all errors in the video steam but makes the process very slow, especially for high resolution, high bitrate files. When the mpeg2 decoder finds a macroblock that it can't decode, it overwrites it with a solid-colored black macroblock. If there are more macroblocks until the next slice, it either skips them (leaving behind whatever was there from the previous frame) or also replaces them with black macroblocks. Skipping is never allowed in I-Pictures so repaired errors on those will show up as black horizontal lines.

A proper mpeg2 decoder (like the JVC 30K) will do the above automatically while playing your file (so repair is not needed). I wrote this tool because most PC decoders designed for DVD playback simply can't cope with errors. They will either crash or skip the entire frame(s) causing noticeable pauses during playback. Due to the way MPEG2 is defined, it's pretty much impossible to really fix errors. Best you can do is try to recover from them. I chose to use black macroblocks to mask the errors because they seemed least noticeable to me (especially when they occur near the black border of the screen). There's other repair options which I may explore in the future (borrowing macroblocks from previous frames, etc.).

You may also like to know that the program does continuity checks on both video and audio packets. So you may skip running the EC utility if you like. If you're recording from cable, it also has the advantage of doing continuity checks in a way that won't report false errors like TSReader, etc.

-Mark

For satellite, there seems to always be a single slice per macroblock
row, but for OTA you often have 2-3 slices per row.
Multiple slice headers per row is the mark of a Harris/Lucent "Flexicoder"
HD MPEG-2 encoder widely used for OTA. 1080i will have 3 slices per row
and 720p will have 2. This is a function of the hardware architecture of
the Flexicoder that uses 6 SD encoder chips that execute pretty much
independently of each of each other. Each chip starts it's bitstream with
a slice header.

On all other encoders like the Harmonic MV400 and MV450, the chip
partitions are done vertically, so each chip does entire rows and multiple
slice headers aren't necessary (although you can configure the encoder
to have multiple slice start codes per row to decrease the decoder error
recovery time within a row).

If you really analyze a Flexicoder video stream, you'll see that motion
vectors never cross chip partitions and that automatic I-frame insertion
is done independently on each chip (by coding all intra blocks for that
partition in an overall P-frame).

Ron

Wiz,

The new JVC 5U does not like streams where commercials have been removed with HDTVtoMPEG2.

Very often, the transition triggers a very noticeable lip-sync delay.

Could your tool be improved to mask the audio discontinuities introduced by the editing, making the 5U usable with these streams?

Mark

Is it possible to add the MPEGRepair Utility code to the AVX1 recording software to be an “on the fly” real time process when the files captured on a PC or to a D-VHS deck?

Originally posted by robena
Wiz,

The new JVC 5U does not like streams where commercials have been removed with HDTVtoMPEG2.

Very often, the transition triggers a very noticeable lip-sync delay.

Could your tool be improved to mask the audio discontinuities introduced by the editing, making the 5U usable with these streams?
Cris Moore is working on this. See this thread:

http://www.avsforum.com/avs-vb/showthread.php?s=&threadid=452774

Ron

Originally posted by dr1394
Cris Moore is working on this.

Yep, I know, but it would be nice to be able to (audio) repair already edited streams!

Originally posted by dr1394
Multiple slice headers per row is the mark of a Harris/Lucent "Flexicoder"
HD MPEG-2 encoder widely used for OTA. 1080i will have 3 slices per row
and 720p will have 2. This is a function of the hardware architecture of
the Flexicoder that uses 6 SD encoder chips that execute pretty much
independently of each of each other. Each chip starts it's bitstream with
a slice header.

On all other encoders like the Harmonic MV400 and MV450, the chip
partitions are done vertically, so each chip does entire rows and multiple
slice headers aren't necessary.

Ron

Hi Ron,

Good to hear from you again. Without your inspiration, I probably would never have written this program.

I actually wish Dish would use more slices per row since it allows error recovery with less lost information. With Dish, getting an error at the start of a slice means you're losing the entire 1920x16 pixel wide row. On OTA, I often found cases where only a single 40 macroblock slice was bad. In practice, those errors were often not even noticable without using my program (assuming low-motion scenes).

Since you're the mpeg2 master, maybe you can shed some light on the mysterious 0x000001B4 start code. I can't find much information about it other than "sequence error". Where does this come from? Is it inserted by the receiver or at the broadcast station? It seems more common for OTA. Right now, I treat it like any other error but was wondering if there's something special you can do with it (is it followed by any useful data?).

-Mark

Originally posted by mkerdman
Mark

Is it possible to add the MPEGRepair Utility code to the AVX1 recording software to be an “on the fly” real time process when the files captured on a PC or to a D-VHS deck?

No. As I explained, the program is essentially an MPEG2 decoder. Try finding a software MPEG2 decoder that can decode HDTV on a 1 Ghz machine (like the AVX) without hardware assistance. :)

It would simply be too slow to do in real-time unless the AVX was upgraded to something like a 2 Ghz+ machine.

-Mark

Since you're the mpeg2 master, maybe you can shed some light on the mysterious 0x000001B4 start code. I can't find much information about
it other than "sequence error". Where does this come from? Is it inserted
by the receiver or at the broadcast station? It seems more common for
OTA. Right now, I treat it like any other error but was wondering if
there's something special you can do with it (is it followed by any useful
data?).
The 0x000001b4 start code is the "sequence_error_code". Here's what
MPEG-2 has to say:

"The use of the start codes is defined in the following syntax description
with the exception of the sequence_error_code. The sequence_error_code
has been allocated for use by a media interface where uncorrectable errors
have been detected."

So I'd say that if it appears in the video stream, it's just a warning that
an upstream error correction scheme (most likely a Reed-Solomon
block code error in a receiver) has found an error. You still have to find the
actual bad bits after the sequence_error_code.

Ron

Originally posted by robena
Wiz,

The new JVC 5U does not like streams where commercials have been removed with HDTVtoMPEG2.

Very often, the transition triggers a very noticeable lip-sync delay.

Could your tool be improved to mask the audio discontinuities introduced by the editing, making the 5U usable with these streams?

I'm aware of that issue. It's one of the reasons I stopped using HDTVtoMPEG2 for editing my recordings. I have not used it in a long time but last I checked it also didn't always properly trim the video on GOP boundaries either. I've been using Womble's MPEG Wizard instead. If you enable the 'GOP Trim' option, it produces decent results. But you definitely need to remux the output because it strips all null packets and does some funky things to the data alignment. I also heard it doesn't handle field repeat flags (3:2 pulldown) but that shouldn't matter if you're remuxing.

I wish I could help out on that project but I just don't have the time. Luckily (or not depending how you see it), I was between jobs when I started MPEG2Repair so I had more time to kill. Unfortunately, my program doesn't have the infrastructure necessary to do anything useful with audio data (other than check for continuity errors). To make any audio changes/repair would take a lot of work. I'll keep it on the "to-do" list for the future.

I think the current H2M author is on the right track... so hopefully it will get fixed eventually.

-Mark

Originally posted by Wizziwig
I've been using Womble's MPEG Wizard instead.

Wizard is just too buggy for that. With some streams it works, and with others it's a real mess.

In particular, it handles drops very badly losing audio sync very easily.

Besides, H2 has a much much faster GUI for editing. With the keyboard shortcuts, it takes around 2 minutes to edit a one hour show.


I also heard it doesn't handle field repeat flags (3:2 pulldown) but that shouldn't matter if you're remuxing.

I reported this bug to Womble, and they fixed it, at least for the particular movie I was trying to mux that used the repeat flags.

Originally posted by Wizziwig
No. As I explained, the program is essentially an MPEG2 decoder. Try finding a software MPEG2 decoder that can decode HDTV on a 1 Ghz machine (like the AVX) without hardware assistance. :)

It would simply be too slow to do in real-time unless the AVX was upgraded to something like a 2 Ghz+ machine.

-Mark

Many of us have or would get a 2 Ghz+ machine to run a souped up AVX1 with integrated MPEGRepair so that recording/arciving became a i-pass error-masked affair.


Also, it woul greatly improve results when using chasing playback by having MyHD/AcccessDTV playing a recording in progress.

Wiz,
I want to thank you for the great software. I tried it out on two 20 Gig per hour HD files that I had recorded from satellite. These became smoothly playable with DVHStools / Ravanescent codex and also with Fusion software. Without repair they would freeze the software at start of play not even displaying a single frame. Elecard player could previously display them but very with very broken audio and video on my 2.24 Gig machine. The repair takes a least twice as long as to play the file but it is worth it.
Thanks John

Mark,
Thanks for the detailed explanation of the error log file created by MPEG2Repair. I also started playing with NullPacketSaver. Very nice. Now that we have NullPacketSaver, I would love to see a command line version of MPEG2Repair. This way I can make a batch file which will run MPEG2Repair followed by NullPacketSaver.

The goal would be to simplify the creation of two archives. One archive would be an output file from MPEG2Repair for transfer to D-VHS. The second archive would be null stripped files split into 4.47 GB chunks for DVD-R (along with the .nul file). I've started to do this because it

1. Let's me watch a show just by popping in a D-VHS tape,
2. keeps my hard drives clean, and
3. provides a lossless, error-free backup on DVD-R, and
4. provides a redundant archive, which is good in case one of the archives gets lost or damaged.

I'm sure a command line version of MPEG2Repair would be handy in some other scripted process flows. :)

-Dylan

Originally posted by robena

The new JVC 5U does not like streams where commercials have been removed with HDTVtoMPEG2.

Very often, the transition triggers a very noticeable lip-sync delay.



Does HDTVtoMPEG2 cause lip-sync issues with streams archived to a JVC30K if HDTVtoMPEG2 is used to trim the excess material from the beginning and ends of PC HD captures?

What the best program for this simple form of editing?

Originally posted by dahester
Mark,
Thanks for the detailed explanation of the error log file created by MPEG2Repair. I also started playing with NullPacketSaver. Very nice. Now that we have NullPacketSaver, I would love to see a command line version of MPEG2Repair. This way I can make a batch file which will run MPEG2Repair followed by NullPacketSaver.

The goal would be to simplify the creation of two archives. One archive would be an output file from MPEG2Repair for transfer to D-VHS. The second archive would be null stripped files split into 4.47 GB chunks for DVD-R (along with the .nul file). I've started to do this because it

1. Let's me watch a show just by popping in a D-VHS tape,
2. keeps my hard drives clean, and
3. provides a lossless, error-free backup on DVD-R, and
4. provides a redundant archive, which is good in case one of the archives gets lost or damaged.

I'm sure a command line version of MPEG2Repair would be handy in some other scripted process flows. :)

-Dylan

It would be relatively easy to make a command-line version since that's how it started originally. It also used to process mpeg2 elementary streams but I dropped that support because it didn't seem useful for HD (which usually comes in TS files).

Do you actually need a text-mode version of the tool, or can I simply add command-line arguments for input/output paths to the existing GUI version? The only thing missing from a GUI version would be the error return codes that one normally tests in batch files.

Originally posted by mkerdman
Many of us have or would get a 2 Ghz+ machine to run a souped up AVX1 with integrated MPEGRepair so that recording/arciving became a i-pass error-masked affair.


Also, it woul greatly improve results when using chasing playback by having MyHD/AcccessDTV playing a recording in progress.

Well... I can't really get into the details but patching things after-the-fact like my tool does is really not the appropriate solution. Once data is missing/corrupted there's really no way to restore 100% of the original. If the AVX is still introducing errors (and I'm not saying it is), then it's something that needs to be fixed by Richard/169time. I also feel that my tool should remain an optional process because it is not necessary for all decoders and may not do as good of a job in some situations.

-Mark

Originally posted by mkerdman
Does HDTVtoMPEG2 cause lip-sync issues with streams archived to a JVC30K if HDTVtoMPEG2 is used to trim the excess material from the beginning and ends of PC HD captures?

What the best program for this simple form of editing?
No, H2 does not. And it's by far the best program to trim TS files.

Originally posted by robena
No, H2 does not. And it's by far the best program to trim TS files.

Robert

Thanks, that's what I have been using, but, I have not watched all the archives to see if any lip-sync issues existed.

I have never tries Womble which has also been mentioned as suitable for this purpose.

Version 1.0.0.4 is now available. Very minor/quick changes (see first post). Fixed a crash bug which appeared in one of my recordings and improved default program selection for OTA. It should now pick the first program found instead of the last (usually weather, spanish, etc.).

Have fun.

-Mark

Originally posted by mkerdman
I have never tries Womble which has also been mentioned as suitable for this purpose.
Womble will give you lip-sync problems galore.

Originally posted by Wizziwig
Well... I can't really get into the details but patching things after-the-fact like my tool does is really not the appropriate solution. Once data is missing/corrupted there's really no way to restore 100% of the original. If the AVX is still introducing errors (and I'm not saying it is), then it's something that needs to be fixed by Richard/169time. I also feel that my tool should remain an optional process because it is not necessary for all decoders and may not do as good of a job in some situations.

-Mark

Mark

Just last night I watched a 169Time AVX1 “D” 2-hour feature film DVHS tape capture through an LG 3410 which had a single glitch whose origins are hard to attribute.

From what you have said, had I used the MPEGRepair Tool on a PC capture of the same film and then archived it to DVHS, while improving playback on some decoders such as PCI capture cards software players, it MIGHT HAVE present more glitches on playback through either the JVC 30K or the LG 3410 and possibly the Samsung T165 than the single glitch the direct to DVHS capture did.

If that’s true, the MPEGRepair Tool could be made optional upon AVX1 capture if you and Richard were to agree.

My idea before reading your comment above, was to capture everything on PC, repair each capture, and then archive to DVHS.

However, would that possibly result in the 3410 glitching more?

Some testing is required, and, I will do it.

Mark,

How can I tell MPEG2Repair that I want the output file to be several files of a specific size ?

Thanks again for this great tool.

J.

Originally posted by mkerdman
Mark

Just last night I watched a 169Time AVX1 “D” 2-hour feature film DVHS tape capture through an LG 3410 which had a single glitch whose origins are hard to attribute.

From what you have said, had I used the MPEGRepair Tool on a PC capture of the same film and then archived it to DVHS, while improving playback on some decoders such as PCI capture cards software players, it MIGHT HAVE present more glitches on playback through either the JVC 30K or the LG 3410 and possibly the Samsung T165 than the single glitch the direct to DVHS capture did.

If that’s true, the MPEGRepair Tool could be made optional upon AVX1 capture if you and Richard were to agree.

My idea before reading your comment above, was to capture everything on PC, repair each capture, and then archive to DVHS.

However, would that possibly result in the 3410 glitching more?

Some testing is required, and, I will do it.

If you don't change any of the default INI file settings, then repair should be very safe. My program will never introduce glitches that were not there to begin with (at least nobody has ever reported such a bug). The reason I would make repair optional is because a good decoder can recover some errors in ways that I can't. Here's an example:

Let's say you have an error in an I-Frame. According to the mpeg2 spec, you're not allowed to skip any macroblocks in such pictures. So when I detect an error on this type of frame, I'm forced to replace any missing/corrupted macroblocks with something valid - I use black macroblocks. But in theory, a decoder could do something else such as skipping the rest of that slice/row and moving on to the next one. If there is no motion in the scene and the decoding buffers contain a previous frame, you may not even notice that those pixels were never updated. But you may notice if black pixels appear there as a result of my repair. Of course for many/most people here their decoder isn't this intelligent and would skip that entire frame, display random garbage, or worse.

My program does its best to regenerate a file that follows the ISO 13818-1, 13818-2 specs. I suggest people look at the log and watch those spots for themselves to determine if they prefer how their decoder handles the error compared to mine. For what it's worth - I watch 169time/Dish6000 recordings on a JVC30K and always run them through my program first. I have yet to find a case where an error looked worse after my program. :)

-Mark

Originally posted by Johnny Begood
Mark,

How can I tell MPEG2Repair that I want the output file to be several files of a specific size ?

Thanks again for this great tool.

J.

Unfortunately, no. That's why I wrote the extra NullPacketSaver program. Due to the way my program does the repair, it often needs to go over and patch the output file in random places. It would complicate things too much if the output file was split into several segments. It's something I'll look into for the future but it's not likely to be added any time soon.

Originally posted by Wizziwig
If you don't change any of the default INI file settings, then repair should be very safe. My program will never introduce glitches that were not there to begin with (at least nobody has ever reported such a bug). The reason I would make repair optional is because a good decoder can recover some errors in ways that I can't. Here's an example:

Let's say you have an error in an I-Frame. According to the mpeg2 spec, you're not allowed to skip any macroblocks in such pictures. So when I detect an error on this type of frame, I'm forced to replace any missing/corrupted macroblocks with something valid - I use black macroblocks. But in theory, a decoder could do something else such as skipping the rest of that slice/row and moving on to the next one. If there is no motion in the scene and the decoding buffers contain a previous frame, you may not even notice that those pixels were never updated. But you may notice if black pixels appear there as a result of my repair. Of course for many/most people here their decoder isn't this intelligent and would skip that entire frame, display random garbage, or worse.

My program does its best to regenerate a file that follows the ISO 13818-1, 13818-2 specs. I suggest people look at the log and watch those spots for themselves to determine if they prefer how their decoder handles the error compared to mine. For what it's worth - I watch 169time/Dish6000 recordings on a JVC30K and always run them through my program first. I have yet to find a case where an error looked worse after my program. :)

-Mark

Mark

I archive primarily to DVHS.

Up until now I have found that the LG 3410 played the old A85 169Time AVX1 tapes glitch-free, and, it does equally well with the 08D pre-release.

The LG 3410 decoder might be correcting errors I never see.

Do you think I would be best served archiving the original capture, or, always using your tool first.

I ask because I may well want to re-archive my DVHS library to Blu-Ray or HD-DVD someday and I have no guarantee how decoders such as those in a next-gen optical recorder/player will handle the transmission/reception/capture errors.

still only getting the 03 version off your website...not 04.

Thanks

Never mind...it's amazing what a web page refresh will do...:D

But in theory, a decoder could do something else such as skipping the
rest of that slice/row and moving on to the next one. If there is no motion in
the scene and the decoding buffers contain a previous frame, you may not even
notice that those pixels were never updated.
No theory required. That's exactly what MPEG-2 decoders do (unless concealment
vectors are present). Here's a graphic example of a single bit error in an
I-frame with low motion:

http://www.avsforum.com/avs-vb/attachment.php?s=&postid=4180853&fullpage=1

Same I-frame, but with the reconstruction buffer cleared to zeroes before
decoding the frame:

http://www.avsforum.com/avs-vb/attachment.php?s=&postid=4180859&fullpage=1

Ron

Let's say you have an error in an I-Frame. According to the mpeg2 spec, you're not allowed to skip any macroblocks in such pictures. So when I detect an error on this type of frame, I'm forced to replace any missing/corrupted macroblocks with something valid - I use black macroblocks. But in theory, a decoder could do something else such as skipping the rest of that slice/row and moving on to the next one. If there is no motion in the scene and the decoding buffers contain a previous frame, you may not even notice that those pixels were never updated. But you may notice if black pixels appear there as a result of my repair. Of course for many/most people here their decoder isn't this intelligent and would skip that entire frame, display random garbage, or worse.

The least noticeable option might be to replace the single bad I-frame block with the corresponding contents of the preceding frame if that's possible. Though I guess that would envolve re-encoding that block.

- Tom

Originally posted by Wizziwig

Do you actually need a text-mode version of the tool, or can I simply add command-line arguments for input/output paths to the existing GUI version? The only thing missing from a GUI version would be the error return codes that one normally tests in batch files.

I think just adding command line arguments for the I/O files to the existing GUI version would be fine (and of course it would launch into repairing and then exit upon completion without having to press any buttons in the GUI). Thanks again for your efforts.

-Dylan

Originally posted by dr1394
No theory required. That's exactly what MPEG-2 decoders do (unless concealment
vectors are present). Here's a graphic example of a single bit error in an
I-frame with low motion:

http://www.avsforum.com/avs-vb/attachment.php?s=&postid=4180853&fullpage=1

Same I-frame, but with the reconstruction buffer cleared to zeroes before
decoding the frame:

http://www.avsforum.com/avs-vb/attachment.php?s=&postid=4180859&fullpage=1

Ron

The reason I said "in theory" is because most of the PC decoders designed for DVD playback don't follow this rule. The Intervideo ones for example, just skip the entire frame. When watching, it shows up as random pauses as it waits to sync up with audio. I guess it depends on the user but I find random black squares less distracting than those pauses. Then there's other errors like bad motion vectors. In theory those should be ignored, but I've seen decoders that simply crash because they don't do any bounds checks on memory buffer access during motion compensation. People really need to check their particular decoder to see what it does.


Originally posted by trbarry
The least noticeable option might be to replace the single bad I-frame block with the corresponding contents of the preceding frame if that's possible. Though I guess that would envolve re-encoding that block.

- Tom

Yeah... that's something I'm going to look into for the future. Main problem is that there's no guarantee that the previous p-picture has an intra-coded block in that position and the previous i-picture is likely too far away in time to provide a useful sample. The tool is already doing a re-encode of sorts in order to bring the luminance of the corrupted macroblock down to black. It was the simplest fix I could think of and similar to the DC only intra-blocks originally suggested by Ron. If you check the screen positions of 169time errors (at least on the old software versions) you will see why that strategy usually results in an invisible/perfect repair.


Originally posted by mkerdman
Mark

I archive primarily to DVHS.

Up until now I have found that the LG 3410 played the old A85 169Time AVX1 tapes glitch-free, and, it does equally well with the 08D pre-release.

The LG 3410 decoder might be correcting errors I never see.

Do you think I would be best served archiving the original capture, or, always using your tool first.

I ask because I may well want to re-archive my DVHS library to Blu-Ray or HD-DVD someday and I have no guarantee how decoders such as those in a next-gen optical recorder/player will handle the transmission/reception/capture errors.

Well, you can keep doing what you're doing. If the optical devices down the road have problems, you can then run your archives through my tool before storing them to disc. In my experience, most of the hardware decoders should deal with errors. After all, errors are pretty much expected for OTA transmission. This whole issue is more of a problem for the DVD decoders because they expect perfect data to be coming off the disc. While on the archiving topic, I will say that I've had very bad experience with DVHS. I have a refurbished JVC 30K (with all the updates) and have rarely seen a recording without problems. Maybe it's my choice of tape - Fuji SVHS. In any event, I always record directly to hard-drive and archive to DVD-R to avoid introducing additional errors due to tape. I do still use the JVC to watch all my recordings by streaming files to it via firewire. I'm seriously considering getting a MyHD card to replace the JVC.

-Mark

I just thought I should congratulate the author on such a great program. Bofore using this software I could not edit my CITYTV-HD recordings of Enterprise, using even the latest beta of HDTV2Mpeg2. After running the files through this utility, voila! , they are fully accesible for editing.

Thanks!


Marc.

Originally posted by dahester
I think just adding command line arguments for the I/O files to the existing GUI version would be fine (and of course it would launch into repairing and then exit upon completion without having to press any buttons in the GUI).
I second that, I also need to be able to automatize the process.

Originally posted by dahester
I think just adding command line arguments for the I/O files to the existing GUI version would be fine (and of course it would launch into repairing and then exit upon completion without having to press any buttons in the GUI). Thanks again for your efforts.

-Dylan

Originally posted by robena
I second that, I also need to be able to automatize the process.

I think you guys probably need a text-mode version. If you're going to launch it from a batch file, how will you know when it's done so you can proceed with the script? The GUI version would return instantly and then continue the repair/scan in the background. You probably need something that doesn't return when executed until it's done. Or are you using a more complex scripting system than simple DOS batch files?

Originally posted by Wizziwig
I think you guys probably need a text-mode version. If you're going to launch it from a batch file, how will you know when it's done so you can proceed with the script? The GUI version would return instantly and then continue the repair/scan in the background. You probably need something that doesn't return when executed until it's done. Or are you using a more complex scripting system than simple DOS batch files?
I could of course check the size of the file being generated, and decide that the repair is done when it stops growing (I use something more evolved that .BAT files for scripting), but a text mode version will be of course preferable.

The only draw back if that it will make you maintain and post 2 versions instead of one, so that's up to you if you think that's not too much hassle.

Anyway, text mode or returning GUI, THANKS!

Mark,

Do you feel that your program is ready to be used with other data instead of just the 169time system?


I am asking because I ran your program on a 27 Gbyte file that was converted from the HDTIVO (Directv High Def receiver/PVR).

it passed with flying colors ie.It found no errors and the repaired file was the same exact size as the original.

HOWEVER, MYHD is obviously having trouble with the file because the video breaks up throughout the file on playback.

Thanks,

Joe

May have seen the same thing when processing a file from the R5000-HD. Looking for tools that can generically run on a ts stream whether there is an issue or not.

Unfortunately, I didn't save the original stream so it could have been in the source.

Originally posted by Joe Q
Mark,
HOWEVER, MYHD is obviously having trouble with the file because the video breaks up throughout the file on playback.

Thanks,

Joe

I've used Mark's utility on 10 movies coming from various source so far. All of them were not watchable with MyHD before (no sound at all and lot of glitches...). All of them are now watchable with still some video glitches (but a lot less) but no audio problem.

I've tried several version of MyHD and I figured out that the best one to play unperfect TS streams is version 1.62.3. The version 1.63 lost audio almost on each glitch (you need to pause and restart to have it back). And the versions before produce more audio glitches.

J.

See there : http://www.avsforum.com/avs-vb/showthread.php?s=&threadid=455882

Mark,

Maybe it's gonna sound futile but it would be cool if your utility could be minimized. I use to process several files at the same time and I just can get rid of all the windows... ;)

J.

Mark,
I had not thought about the command line returning right after launching the GUI. I'm not as gifted a scripter as some (batch files are as far as I go) so I think a text mode version would be nicer, if it's not too much trouble to create. BTW is there any way for the GUI version to keep control of the command prompt until it's done?

I have an update after using this tool on many AVX-1 recordings. I found another bug in my "08D6" recordings which I could not identify the source of until now. The symptom is when I play my recordings (trasferred to D-VHS) on the JVC 30k deck, the JVC decoder shows occasional loss of audio and video. It's completely repeatable by rewinding the tape and replaying the section where the dropout occured.

I was initially suspicious of MPEG2Repair, but last night I made two copies of a movie, one pre-repair and one post-repair. It turns out the dropouts occur in the exact same places on both tapes. (BTW the recording was Bad Boys II, which was the cleanest recording I've made from the AVX-1 with only 3 frames that had corrupted data, and zero continuity errors). Now here's where it gets interesting: the suspicious parts of both recordings play back perfectly on ALL other equipment at my disposal (MyHD, Mits 1100U + Samsung T165, and Mits 2000U + LG LST-3410A). I did notice a single frame stutter on the Samsung shortly after the positions where the dropouts were happening on the JVC 30k, but no loss of audio.
BTW the JVC 30k's firewire output drops out simultaneously with the internal decoder dropping out.

Bottom line: This may mean the AVX-1 is subtly, erroneously stamping the PTSes and/or PCR in such a way that the JVC decoder can't handle them, but other decoders can. Another possibility is a slight buffer underrun or overrun in either demuxed audio or video output which causes the 30k some trouble but not the other decoders. Some people were reporting similar problems with the JVC 30k and 08E6 firmware; I think I'm seeing the same issue with 08D6.

-Dylan

Originally posted by Johnny Begood
I've tried several version of MyHD and I figured out that the best one to play unperfect TS streams is version 1.62.3. The version 1.63 lost audio almost on each glitch (you need to pause and restart to have it back). And the versions before produce more audio glitches.




Thanks for the tip - I will give it a shot.

There is lot of MYHD bashing going on in a well known forum dedicated to the TIVO but for High Def shows, MYHD is the only choice for playing back files made from the HDTIVO.

Joe

Originally posted by Johnny Begood
Mark,

Maybe it's gonna sound futile but it would be cool if your utility could be minimized. I use to process several files at the same time and I just can get rid of all the windows... ;)

J.

Wait for next version. I already fixed this along with many other user-interface improvements.

Originally posted by dahester

Bottom line: This may mean the AVX-1 is subtly, erroneously stamping the PTSes and/or PCR in such a way that the JVC decoder can't handle them, but other decoders can. Another possibility is a slight buffer underrun or overrun in either demuxed audio or video output which causes the 30k some trouble but not the other decoders. Some people were reporting similar problems with the JVC 30k and 08E6 firmware; I think I'm seeing the same issue with 08D6.

-Dylan

For audio, I think the buffer under/over run is most likely the problem. I've seen this happen frequently with recordings from DVB cards. I've also had audio drop-outs on older AVX software when running on AVX machines slower than ~P3-800. You might be able to fix the audio drop-outs by shifting the audio packets with Balazer's TStoATSC3. I used to have a similar shifting feature in MP2R but disabled it because it needed more work.


Originally posted by Joe Q
Mark,

Do you feel that your program is ready to be used with other data instead of just the 169time system?


I am asking because I ran your program on a 27 Gbyte file that was converted from the HDTIVO (Directv High Def receiver/PVR).

it passed with flying colors ie.It found no errors and the repaired file was the same exact size as the original.

HOWEVER, MYHD is obviously having trouble with the file because the video breaks up throughout the file on playback.

Thanks,

Joe

I don't know the source of all the samples that people have sent me but it's possible that I've never tried anything from the HDTivo. If you like, you can send me a small clip (<10 MB) to mpeg2repair@adelphia.net. Did the error log summary contain an actual frame count and sequence time duration? If not, then my tool probably didn't find any mpeg2 picture data in the file (hence no errors).

If I can't figure it out, maybe Ron (dr1394) might have a clue. He's the true mpeg2 master - I'm just a mere apprentice. :)

-Mark

Originally posted by Joe Q
Thanks for the tip - I will give it a shot.

There is lot of MYHD bashing going on in a well known forum dedicated to the TIVO but for High Def shows, MYHD is the only choice for playing back files made from the HDTIVO.

Joe Actually there are quite a few software-only players that can handle HD playback, including HD from a tivo.

I tried this software, thanks for making it. But it says it can't find PID values. Does that mean it's not actually recording anything? Because the files are reasonably sized, 30MB for 30 seconds or so, so I wonder what it is recording. Anyway, I'll make a smaller one and email it to you. Thanks again.

Originally posted by hokkemirin
I tried this software, thanks for making it. But it says it can't find PID values. Does that mean it's not actually recording anything? Because the files are reasonably sized, 30MB for 30 seconds or so, so I wonder what it is recording. Anyway, I'll make a smaller one and email it to you. Thanks again.
Blank TS files are typical when you try to dump 5C copy protected material.

Good program. Only when I did one 30 show the error report was 20 megs long and the file was 1 gig smaller because it cut out the 2nd channel.

When I did other 60 min show, it did not cut out the other channel and file was the same size and the second channel was not seen in VLC.

Maybe because I am using WINHD and it encrips the streem.

Why so amny errors and where is the other channel?

Originally posted by GoTimothy
Good program. Only when I did one 30 show the error report was 20 megs long and the file was 1 gig smaller because it cut out the 2nd channel.

When I did other 60 min show, it did not cut out the other channel and file was the same size and the second channel was not seen in VLC.

Maybe because I am using WINHD and it encrips the streem.

Why so amny errors and where is the other channel?

If the data is encrypted, then there will be no way for the program to make any sense of it. That could explain why you're getting a huge error log.

The program only leaves a single program/channel in a repaired file. This was done because it's what most users want and because it improves compatibility. Some players get confused by multiple programs or end up selecting the wrong one. If you wish to leave a different program in the repaired file, enter its number into the "Program" edit box. You can get the number from a program like TSReader Lite. Next version will no longer require TSReader since I added a drop-down list of available programs.

-Mark

Originally posted by Wizziwig


The program only leaves a single program/channel in a repaired file. This was done because it's what most users want and because it improves compatibility. Some players get confused by multiple programs or end up selecting the wrong one. If you wish to leave a different program in the repaired file, enter its number into the "Program" edit box. You can get the number from a program like TSReader Lite. Next version will no longer require TSReader since I added a drop-down list of available programs.

-Mark

Mark, when you remove the other programs/channels, do you convert that data to null packets and preserve the ATSC 19.3Mb/sec data rate?

DonP

Originally posted by Wizziwig

For audio, I think the buffer under/over run is most likely the problem. I've seen this happen frequently with recordings from DVB cards. I've also had audio drop-outs on older AVX software when running on AVX machines slower than ~P3-800. You might be able to fix the audio drop-outs by shifting the audio packets with Balazer's TStoATSC3. I used to have a similar shifting feature in MP2R but disabled it because it needed more work.

Unfortunately the audio and video drop out at the same time on the JVC 30k (I verified it's a problem on two different 30k decks). I tried TStoATSC3 and it doesn't clear up the problem. Since it only affects the JVC 30k I can live with it. Ironic though, since the JVCs were the most compatible with older versions of AVX-1 software.

I was going to send you a clip, but you have the same setup I do (an AVX-1 with a Dish 6000). Make sure to watch your movies all the way through. It's hard to catch just by sampling.

-Dylan

Mark,

As I was using your utility on a movie, I was wondering why the output file was smaller (a lot, around 35%) than the input file. I discovered that the file output by MPEG2Repair was cleaned of null packets. Is it also a function of this utility ???

As you mentioned that you've got something else to do this job, I was surprised.

I've also tried on an already null packet cleaned file. The original file size is 4,4 GO and the output file is 3,9. Where are the 500 MO missing ?

J.

J.,
I've seen this before also. If your recording originally came from the Dish 5000 modulator, it will have '0x1FEF' null packets rather than the standard '0x1FFF' nulls. Mark's program leaves in the 0x1FFF nulls but will strip out everything else except the main program. IMO it's kind of a problem since recordings from the Panasonic TU-DST5X tuner have this strange property that stripping out nulls can make the resulting file have very jerky playback on many decoders. While the jerky playback can happen on other null stripped recordings, smooth playback can usually be restored by reinserting the nulls and restamping the PCR with TStoATSC(3). This is NOT the case with Panny recordings; once the nulls are gone, you may never be able to restore smooth playback.

-Dylan

Hmm.... unless you enable nullpacket stripping via the INI file (it's disabled by default), the program should never drop any packets from the transport without replacing them with null packets. It should work regardless of whether the original null packets use PID 0x1FFF or 0x1FEF. Any additional null packets added by my program will always use PID 0x1FFF. This is done so that the original transport bitrate is maintained. Nobody should ever enable null packet stripping unless they are 100% certain that their decoder will function without them. Technically speaking, a null packet stripped TS file is broken and there's no guarantee of it working properly.

If you don't have the INI change and you're still losing packets, then there's a bug. I'll try to double check this on my end. Also make sure you're using the latest version (1.0.0.4) by checking the exe file properties.

-Mark

Originally posted by dahester
Unfortunately the audio and video drop out at the same time on the JVC 30k (I verified it's a problem on two different 30k decks). I tried TStoATSC3 and it doesn't clear up the problem. Since it only affects the JVC 30k I can live with it. Ironic though, since the JVCs were the most compatible with older versions of AVX-1 software.

I was going to send you a clip, but you have the same setup I do (an AVX-1 with a Dish 6000). Make sure to watch your movies all the way through. It's hard to catch just by sampling.

-Dylan

Just to review, do these drop-outs always occur at the same spots when watching multiple times on the JVC 30K? Does my program find any errors in those spots? Is it isolated to a particular channel? These days, I only record HDNet from Dish and have not seen this problem. I get HBO/SHO from another source because I don't like Dish re-compression of those channels.

Wizziwig, just to clarify your last statement, the FAQ to MPEG2Repair states the following:5) When repairing the stream, data is often added/removed. As a result, if your original file was constant bitrate (i.e 19.4 Mbps), it may no longer be constant after repair. If your decoder requires constant bitrate files, you may have to remux them or try Balazer's TStoATSC utility to get it back to 19.4 Mbps (http://www.cs.rochester.edu/~balazer/atsc/).Does this statement still apply to version 1.0.0.4? If one does not enable null packet stripping, does the bitrate stay constant after the file is repaired, so that the TStoATSC utility is not required?

Mark,

I was using version 1.0.0.2. The INI file was the following :

StripNullPackets=0
StripEarlyAudioPackets=1
IgnorePCRIntervalWarnings=1
IgnoreContinuityWarnings=0
IgnoreRepeatedPacketWarnings=0
FixMacroblockErrors=1

I've just tried on the same movie with version 1.0.0.4 with the following INI file :

StripNullPackets=0
StripEarlyAudioPackets=0
FixMacroblockErrors=1
IgnoreContinuityWarnings=0
IgnorePCRIntervalWarnings=1
IgnoreRepeatedPacketWarnings=1
IgnoreAudioDelayWarnings=1

And the winner is...v1.0.0.4 which does not seem to remove anything more than errors. The resulting file is almost the same size than the original one.

I have just watched a movie processed by v1.0.0.2. It works really great. I'm now using v1.0.0.4. As my system (MyHD) handles correctly null packet removed streams, if I want MPEG2Repair to repair AND remove null packets, do I just have to change the INI file corresponding line to 1 ?

Thanks,

J.

Originally posted by stjr
Wizziwig, just to clarify your last statement, the FAQ to MPEG2Repair states the following:Does this statement still apply to version 1.0.0.4? If one does not enable null packet stripping, does the bitrate stay constant after the file is repaired, so that the TStoATSC utility is not required?

I made some refinements since the first version (where I added that comment to the FAQ) so that repaired files are now virtually identical in bitrate to the original. In my experience, 99% of the repairs now end up using space that was originally occupied by the corrupted bytes. So there will not be any increase/decrease in transport packets. There are rare occasions where I need to insert a packet or two but those are extremely rare and should not affect bitrate by a significant amount. I'll try to update the FAQ to reflect those changes.

Just to be clear, if you're seeing a drop in file size as a result of my program, there are only a few possibilities:

1) Your file had a large amount of data before the first mpeg2 sequence header. Since such data can't be decoded/displayed by any decoder, I always remove it from the transport. This unused data at the start of your file is not replaced by null packets. Typically this only amounts to < 1MByte of data.

2) Your file contains non-transport data. The error log would report packets without sync-bytes. These can't be played/used by any decoder so they are removed without replacement.

3) Bug in my program. Please contact me if you find an example.

-Mark

Originally posted by Johnny Begood
Mark,

I was using version 1.0.0.2. The INI file was the following :

StripNullPackets=0
StripEarlyAudioPackets=1
IgnorePCRIntervalWarnings=1
IgnoreContinuityWarnings=0
IgnoreRepeatedPacketWarnings=0
FixMacroblockErrors=1

I've just tried on the same movie with version 1.0.0.4 with the following INI file :

StripNullPackets=0
StripEarlyAudioPackets=0
FixMacroblockErrors=1
IgnoreContinuityWarnings=0
IgnorePCRIntervalWarnings=1
IgnoreRepeatedPacketWarnings=1
IgnoreAudioDelayWarnings=1

And the winner is...v1.0.0.4 which does not seem to remove anything more than errors. The resulting file is almost the same size than the original one.

I have just watched a movie processed by v1.0.0.2. It works really great. I'm now using v1.0.0.4. As my system (MyHD) handles correctly null packet removed streams, if I want MPEG2Repair to repair AND remove null packets, do I just have to change the INI file corresponding line to 1 ?

Thanks,

J.

Glad to hear it wasn't a bug after all. :)

You could do that... but I recommend using my NullPacketSaver utility instead. It will also remove the null packets but store a record of their positions in a backup file. You can later use this backup file to put the null packets back in case you change players, cards, etc. The backup file is relatively small and can be zipped to make it even smaller.

-Mark

Originally posted by Wizziwig
I made some refinements since the first version (where I added that comment to the FAQ) so that repaired files are now virtually identical in bitrate to the original. Thanks for the clarification, Mark. The first time I processed a file with your application, the file size stayed the same, so I wondered what was going on. I prefer to keep the bitrate constant for decoder compatibility. I've had good results so far, so now I'll give it a real workout. Thanks for the application.

Originally posted by Wizziwig
It would be relatively easy to make a command-line version since that's how it started originally. It also used to process mpeg2 elementary streams but I dropped that support because it didn't seem useful for HD (which usually comes in TS files).

Do you actually need a text-mode version of the tool, or can I simply add command-line arguments for input/output paths to the existing GUI version? The only thing missing from a GUI version would be the error return codes that one normally tests in batch files.
Hi Mark.

I'm a Mac / Unix user, and as such live in a veritably wasteland when it comes to TS repair programs. I actually sought this thread out because it sounded like something that could be run from a command line, and lo-and-behold, other users have made this very request!

I am wondering about the possibility of a commond-line version port to the UNIX layer of Mac OS X (Darwin), and to Linux? Both use gcc as their core compiler and porting to one is a huge step in getting it to the other (though there are differences in "stat" and other low level I/O calls).

For example, dr1394's "xport.c" program actually compiled without modification under darwin, and I was able to port TStoATSC without much trouble.

Obviously your program has a Windows interface, and if it's tightly coupled with the processing module, this won't be possible. However, if the file I/O and TS processing can be "broken out," I for one would beg you for a port. I'm hoping your reference to a "text mode" means that these modules can be used independantly.

Those are big "ifs" but in case it's possible, I would be happy to actually do the port (I have access to Debian Linux as well as Mac OS X / Darwin). I would willingly sign an NDA or whatever... though I know very little about MPEG2 TS format and probably wouldn't be able to disclose anything if I tried. :)

-Pie

Originally posted by EatingPie
Hi Mark.

I'm a Mac / Unix user, and as such live in a veritably wasteland when it comes to TS repair programs. I actually sought this thread out because it sounded like something that could be run from a command line, and lo-and-behold, other users have made this very request!

I am wondering about the possibility of a commond-line version port to the UNIX layer of Mac OS X (Darwin), and to Linux? Both use gcc as their core compiler and porting to one is a huge step in getting it to the other (though there are differences in "stat" and other low level I/O calls).

For example, dr1394's "xport.c" program actually compiled without modification under darwin, and I was able to port TStoATSC without much trouble.

Obviously your program has a Windows interface, and if it's tightly coupled with the processing module, this won't be possible. However, if the file I/O and TS processing can be "broken out," I for one would beg you for a port. I'm hoping your reference to a "text mode" means that these modules can be used independantly.

Those are big "ifs" but in case it's possible, I would be happy to actually do the port (I have access to Debian Linux as well as Mac OS X / Darwin). I would willingly sign an NDA or whatever... though I know very little about MPEG2 TS format and probably wouldn't be able to disclose anything if I tried. :)

-Pie

After further consideration, doing a text-mode version is probably not going to happen. It's not so much because it's difficult but because it would be a pain in the future. This tool is already taking up most of my free time and maintaining 2 versions would make things even more difficult. I also plan to greatly expand this tool in the future by including some editing functionality. This wouldn't mesh well with text-mode.

Isn't there some kind of Windows emulator for Linux? (Wine?). There should be something similar for Mac. This tool uses pretty basic Windows functions so it should run okay on an emulator.

-Mark

I am puzzled as to why a 169Time recording that appears to play fine in MyHD twice caused the attached message from MPEGRepair on the same recording of “Down with Love” both times within the first few minutes.

All my other 169Time files ran through just fine.

Originally posted by mkerdman
I am puzzled as to why a 169Time recording that appears to play fine in MyHD twice caused the attached message from MPEGRepair on the same recording of “Down with Love” both times within the first few minutes.

All my other 169Time files ran through just fine.

This is a generic error that occurs when there are too many sequential corrupted frames in a row. In the current version it's set to about 8 MBytes worth of data. When you previously watched this program, was it from the exact same file that you ran through my tool? If not, maybe it got corrupted while being transfered to the PC. Try watching the original unrepaired file that you have on the PC hard drive to see if it has an error in the last position indicated by the log.

In any event, please send me your error log at mpeg2repair@adelphia.net

Thanks.

Posted new versions of MPEG2Repair (1.0.0.5) and NullPacketSaver (1.02). These updates are to improve user-friendliness/interface. No major changes to functionality. Please keep sending ideas and bug reports for future versions.

-Mark

Originally posted by Wizziwig
This is a generic error that occurs when there are too many sequential corrupted frames in a row. In the current version it's set to about 8 MBytes worth of data. When you previously watched this program, was it from the exact same file that you ran through my tool? If not, maybe it got corrupted while being transfered to the PC. Try watching the original unrepaired file that you have on the PC hard drive to see if it has an error in the last position indicated by the log.

In any event, please send me your error log at mpeg2repair@adelphia.net

Thanks.

The files run through the tool were never on a D-VHS deck- only the PC.

Originally posted by mkerdman
The files run through the tool were never on a D-VHS deck- only the PC.

Well, if you would like me to look at this issue, I would need a sample of the file. If you have a fast internet connection, you can email me samples < 10 MB is size. Easiest way to make samples is to split the original in HDTV2MPEG2 (set segment size to 9 MB to be safe), run it through mpeg2repair again, and then look at the log to see which was the last segment before the error.

Originally posted by Wizziwig
Posted new versions of MPEG2Repair (1.0.0.5) and NullPacketSaver (1.02). These updates are to improve user-friendliness/interface. No major changes to functionality. Please keep sending ideas and bug reports for future versions.
Thanks Mark.

I have some AVX1 DirectTV HBO recordings that normally don't run on my Samsung 165, with constant image tear.

Once repaired with the previous version, they seem to do at first, but after a while, the 165 starts to stutter. Hitting Stop/Play makes it work again, but it does not last.

Any idea if this can be corrected? Would you need a sample?

Originally posted by Wizziwig
Posted new versions of MPEG2Repair (1.0.0.5) and NullPacketSaver (1.02). These updates are to improve user-friendliness/interface. No major changes to functionality. Please keep sending ideas and bug reports for future versions.

-Mark

Mark,

Thanks for the minimize button ;)

Another little bug I've found is when you're processing a file which is on a bad DVD (a dirty DVD for example or scratched or with some burning errors) MPEG2Repair crashes and sometimes crashes the whole PC.

J.

Originally posted by Johnny Begood
Mark,

Thanks for the minimize button ;)

Another little bug I've found is when you're processing a file which is on a bad DVD (a dirty DVD for example or scratched or with some burning errors) MPEG2Repair crashes and sometimes crashes the whole PC.

J.

An application like mpeg2repair which runs in user-space, can't really crash an operating system. It would require something like a device driver failure to take down your whole OS. Most likely the DVD-ROM drivers can't handle reading the corrupted disc. Nothing I can do to help. I suggest copying the disc to hard-drive first or making a backup on another machine.

Originally posted by robena
Thanks Mark.

I have some AVX1 DirectTV HBO recordings that normally don't run on my Samsung 165, with constant image tear.

Once repaired with the previous version, they seem to do at first, but after a while, the 165 starts to stutter. Hitting Stop/Play makes it work again, but it does not last.

Any idea if this can be corrected? Would you need a sample?

That sounds like a muxing problem where it's overflowing the video and/or audio buffers. You would need to remux the file to rebuilt a correct constant-bitrate transport stream. Since I don't plan to add muxing support to mpeg2repair, you will need to find another program to do it.

Search the forums - people have found various ways to multiplex HDTV files.

-Mark

Just curious if anyone else watched/captured 'Terminator' last night on HDNET-Movies. I noticed a couple glitches watching the live feed on my Dish 6000 receiver and sure enough also found them on my recording.

Since these errors were present in the original satellite transmission, I'm wondering if they originated at HDNet, Dish, or just my location. If you recorded this showing last night, can you run it through my tool and report the time positions of any errors? Please include your provider.

Thanks.

-Mark

Originally posted by Wizziwig
Just curious if anyone else watched/captured 'Terminator' last night on HDNET-Movies. I noticed a couple glitches watching the live feed on my Dish 6000 receiver and sure enough also found them on my recording.

Since these errors were present in the original satellite transmission, I'm wondering if they originated at HDNet, Dish, or just my location. If you recorded this showing last night, can you run it through my tool and report the time positions of any errors? Please include your provider.

Thanks.

-Mark

I emailed you my repair log of "The Terminator" captured to PC from a Dish 6000 on 11-01-04 at 2:40 AM.

I did not watch or record "Terminator," but I have seen live and recorded glitches from just about every film shown on the HDNet Movie channel on E*. Last night, I saw a live glitch on "The Manchurian Candidate" for example.

I believe that the problem lies in the satellite signal, because other channels don't glitch like HDNet Movies, but how much effort will it take to prove to E* that it is sending a faulty signal or get E* to take action to correct it? For all I know, the source of the problem could be the HDNet Movie feed itself. Maybe Mark Cuban would take some action to figure this out if he got involved.

I compared Murray's log to mine and found that the errors occur at the exact same places. So it's definitely not a local reception issue. It's a problem with the original transmission - either at HDNet or Dish.

I have attached a copy of my log. Perhaps a fellow member to can compare it to his recording from cable, c-band, etc. to see if they have any glitches at those locations. You may need to do this visually if mpeg2repair doesn't find any errors or you can't transfer the file back to a PC. If people not using Dish don't get these errors, then we know who to blame. :mad:

Thanks.

P.S. This is from the second showing at 12:45 AM Pacific Time. I can also get you a log from the earlier 9 PM showing.

Indeed, I take back my earlier claim about error-prone AVX-1 software being the cause of errors reported by MPEG2Repair. My apologies to Richard et al.

Ok, let's continue using Terminator as a study reference. I missed the 1st chance to record it, but will record the next showing. We can compare the next repair log with those already captured to see if the errors are coming from the original source or during transmission. Lately I've been seeing shorter repair logs via cable captures than Dish on most channels. It looks like there are some real problems with Dish's uplinks.

-Dylan

Originally posted by dahester
Indeed, I take back my earlier claim about error-prone AVX-1 software being the cause of errors reported by MPEG2Repair. My apologies to Richard et al.

Ok, let's continue using Terminator as a study reference. I missed the 1st chance to record it, but will record the next showing. We can compare the next repair log with those already captured to see if the errors are coming from the original source or during transmission. Lately I've been seeing shorter repair logs via cable captures than Dish on most channels. It looks like there are some real problems with Dish's uplinks.

-Dylan

I should note that I edited my error log to remove a handful of errors that were not in Murray's capture. These extra errors were minor and 169time specific. Since we're trying to isolate the cause of transmission errors (not recording errors), I didn't think they were relevant to this discussion.

I have attached the original log if you want to compare it to my previous post (which matched Murray's R5000 results). The R5000 didn't seem to introduce any errors that were not in the original signal.

-Mark

Version 1.0.0.6 now available. Minor changes to add a couple user requested features. See first post for links and details.

-Mark

I posted version 1.0.0.7 yesterday. I suggest everyone grab this update because it fixes some potential crash issues.

-Mark

First time to run it and obtain "Failed to find audio PID for selected program/audio tracks. Repaired file will not contain audio." Yet others apps see it fine, see audio PID, and audio runs. running 0.7.

Isn't there some kind of Windows emulator for Linux? (Wine?). There should be something similar for Mac. This tool uses pretty basic Windows functions so it should run okay on an emulator.


Yuck. I hope you re-reconsider this in the future.

Originally posted by Compromise
First time to run it and obtain "Failed to find audio PID for selected program/audio tracks. Repaired file will not contain audio." Yet others apps see it fine, see audio PID, and audio runs. running 0.7.

What PID and audio format did the other apps detect? How many programs and audio tracks are in the file? (check the drop-down lists after letting it scan for PID's). Might be some bug I introduced in the last version since I changed around some of the audio detection code to add more mpeg1 formats. If you have a broadband connection, I would appreciate seeing a small sample (cut < 5MB with HDTV2Mpeg2) via email to mpeg2repair@adelphia.net

-Mark

Wizziwig
See PMs.

Originally posted by Compromise
Wizziwig
See PMs.

Got it... thanks. For anyone else interested, this file has AC3 audio with a stream type of 0x6. This is normally used for private data but it looks like a few sources are using it to pass AC3 audio. I made a small change in a previous version to deal with this issue for ProjectX files but I'll extend it to cover other sources in the next release.

The audio is also in a PES with a packet length of 0. This is technically wrong for audio and only allowed for PES streams with video. I'm not sure if any of the players/decoders actually care about this sort of thing...

-Mark

Basically I gave Wizziwig a .m2t file generated by VirtualDVHS from an AVX1. Also, I gave him a .ts file which was generated by MPEG Streamclip from the .m2t file.

Originally posted by Compromise
Basically I gave Wizziwig a .m2t file generated by VirtualDVHS from an AVX1. Also, I gave him a .ts file which was generated by MPEG Streamclip from the .m2t file.

I suggest you stick with the .m2t files for now. They are regular transport streams just like ts,tp,trp files and will work with most software designed for U.S. HDTV (including mpeg2repair). There is no need to run them through any additional conversions.

I don't know what Streamclip is but it seems to generate files which are less compatible. In any event, I already fixed the issue and both of your files (TS and M2T) will work fine in the next release.

-Mark

can this program be updated to work with regular mpg streams? I need a program that can repair my mpg files from my HDTV wonder. I'll donate for this functionality ;)

...to work with regular mpg streams?

Or maybe even accept mpg as input fix the errors and save it as atsc ts?

Originally posted by AllTimeSToneD
Or maybe even accept mpg as input fix the errors and save it as atsc ts?

That's asking a lot. Making an ATSC TS from .mpg is no small task. My suggestion for now would be to use VLC to encapsulate your .mpg files to .ts files, then use MPEG2Repair. Afterwards, if you need an ATSC TS use TS2ATSC3.

-Dylan

use VLC to encapsulate your .mpg files to .ts filesHave you tried this? Does it demux the video and audio into elementary streams first and then remux them into ts? More importantly does it keep correct PTS for the audio and video?

One more question, what commandline are you using to do this?

I'm having a problem trying to repair a small .ts clip captured thru the firewire. The clip shows PID's:
video=0x840
audio=0x841

There is only a few errors to begin with and it plays fine, just wanted to see what happens when I run it thru mpeg2repair.

Unfortunately, the audio seems to be missing or something after the repair...it shows the PID's as:
video=0x11
audio=0x14

the video is still there, just no audio. Using WinDVD 5 for viewing. Captured from cable, di$covery channel.

Seems my cable outputs 0x840, 0x800, 0x41, et al....depending on the channel it's on. Do you guys have any idea what I can do so mpeg2repair keeps the audio? I would like to run a few of my captures thru so I know any errors will be masked...I will try it on some samples of the other clips using the different PID locations when I get some time this weekend....

thanks to all. This forum has helped me build my own htpc, a DIY screen (actually 3 now), and install a projector. I have lurked MANY hours on this forum over the last year or so..again thanks to you all.

--ok, should have done more research. Seems the files all have audio when played with media player classic. None of the files have audio in WinDVD. Since WinDVD is the only player I have that can play these smoothly, is there any way to tell mpeg2repair to leave the PID's where they are? Thinking it would be easier to do this than to get Intervideo to even respond.

Originally posted by emp3r0r
Have you tried this? Does it demux the video and audio into elementary streams first and then remux them into ts? More importantly does it keep correct PTS for the audio and video?

One more question, what commandline are you using to do this?

Yes, I've used VLC 0.80 to MUX my own streams. I'm not sure what VLC is doing internally, but I think the .mpg is demuxed and remuxed when the TS is made. I have no idea how well it handles funny streams that have variable GOP size and field repeat flags (a la HBO and Starz). But generally I have found it to be a very good TS muxer for DVD VOB files and mpegs created by TMPGenc. You'll have to do a search in this forum to find the command line. I just use the GUI.

-Dylan

Originally posted by spaceghost
Do you guys have any idea what I can do so mpeg2repair keeps the audio?
Use the latest HDTVtoMPEG2 beta to remap the pids to 0x11 and 0x14.

Thanks robena. I tried that and it didn't make a difference. I believe the mpeg2repair does this as well. Seems when I take a capture of mine and change the PIDs, windvd 5 won't play them.
I downloaded a sample .ts that was captured via a pchdtv tuner card in linux that was using the 0x11/0x14 PIDs to see if windvd 5 could play them. It ran fine.
is it me or is my cable company doing something out of the norm? I don't understand why I can't repair them anyway...the moving, or whatever it's doing of the PIDs shouldn't be causing me a problem.
I've sent in a request to intervideo....we'll see if they even respond.
Do you have any other suggestions besides not repairing them?

btw, i'm using ver 1.0.0.7 mpeg2repair.

Originally posted by spaceghost
Thanks robena. I tried that and it didn't make a difference. I believe the mpeg2repair does this as well. Seems when I take a capture of mine and change the PIDs, windvd 5 won't play them.
I downloaded a sample .ts that was captured via a pchdtv tuner card in linux that was using the 0x11/0x14 PIDs to see if windvd 5 could play them. It ran fine.
is it me or is my cable company doing something out of the norm? I don't understand why I can't repair them anyway...the moving, or whatever it's doing of the PIDs shouldn't be causing me a problem.
I've sent in a request to intervideo....we'll see if they even respond.
Do you have any other suggestions besides not repairing them?

btw, i'm using ver 1.0.0.7 mpeg2repair.

Hi,

Please send me a small sample of an original, unrepaired file that has this problem. Length doesn't matter too much, as long as it's 1-8 MB so it fits in my mail box. Send it to mpeg2repair@adelphia.net. I have WinDVD so I should be able to figure out what's wrong and fix it for the next version.

Thanks.

-Mark

just so everyone knows, Mark was graceous enough to look at my file. We concluded that windvd ver 5 was at fault. Version 6 plays the files just fine. The test sample I downloaded that worked was an ATSC capture that had additional info in the file that the cable capture did not. Guess ver 5 works better if viewing an ATSC capture.

WinDVD trick... Sometimes if you start playing but hear no audio... Hold the rewind button down until it rewinds back to the beginning and starts playing again. Sometimes this causes the audio to kick back in.

Sorry if this has been asked, any way to use this utility on dvds backed up to hard drive. Some dvds for what ever reason have glitches in them when playing from hard drive.

Thanks!

Originally posted by Alan Gouger
Sorry if this has been asked, any way to use this utility on dvds backed up to hard drive. Some dvds for what ever reason have glitches in them when playing from hard drive.

Thanks!

Well, you could convert the .vob files to .ts files using the VLC method Dylan outlined a few posts back. But it's highly unlikely that my utility will help fix anything on a DVD source. DVD's are usually free of the sort of errors/drop-outs that this is designed to repair.

What are you trying to play them on? I'm curious if the problems are isolated to a specific player/software or if the errors show up on all players.

-Mark

Hi Mark

For some reason a few DVD titles are known to not back up very well and its most likely an error in the software used. Not really worth going through any great effort for me because its only a few titles.

I do appreciate your program and want to thank you. Im slowly transferring my AVX library from tape to HD.

Thanks again.

Does MPEG2Repair handle when the packets are not all aligned to 188-byte boundaries, or should I fix that problem before I pass a stream to MPEG2Repair?

Originally posted by balazer
Does MPEG2Repair handle when the packets are not all aligned to 188-byte boundaries, or should I fix that problem before I pass a stream to MPEG2Repair?

Should work fine. It will always resync to the next packet by searching for the repeating sync-byte (0x47) pattern every 188 bytes. It also correctly handles file segments that were cut on non-packet aligned boundaries.

While I'm here, let me answer a couple other private messages:

1) Next version is still on track for release within a week or so. Currently working on a way to restore a/v sync to files with dropped audio and/or video frames. It's a really tricky problem. Hopefully once I get it working, we'll be able to demux and remux files with drop-outs and still maintain proper a/v sync. If anyone knows of another method/tool to do this, please let me know. It would be helpful for verifying my results.

2) People attempting to repair really old 169time recordings (especially those from DirecTV) may need to remux their files. My tool is not a muxer and can't deal with decoder buffer overrun/under-run issues. If your repaired file still only plays correctly on some devices, this is likely your problem.

-Mark

Project X has an A/V sync algorithm for bitstream errors. I don't know if it's
"reference" quality, but it's something.

Be aware that this algorithm is based on GOP timecodes, which doesn't work
for all bitstreams. Video streams without GOP headers and video streams
with inverse telecine but the GOP timecode counts input frames rather
than output frames will break Project X.

I haven't looked at many 169time files, but even the newest ones have T-STD
buffer problems. Not as bad as older files though.

Ron

Originally posted by Wizziwig
1) Next version is still on track for release within a week or so. Currently working on a way to restore a/v sync to files with dropped audio and/or video frames. It's a really tricky problem. Hopefully once I get it working, we'll be able to demux and remux files with drop-outs and still maintain proper a/v sync.
Mark, that would be really an awesome feature.

I need very often to demux/remux, and as Ron said, ProjectX does not always work.

Originally posted by dr1394
Project X has an A/V sync algorithm for bitstream errors. I don't know if it's
"reference" quality, but it's something.

Be aware that this algorithm is based on GOP timecodes, which doesn't work
for all bitstreams. Video streams without GOP headers and video streams
with inverse telecine but the GOP timecode counts input frames rather
than output frames will break Project X.

I haven't looked at many 169time files, but even the newest ones have T-STD
buffer problems. Not as bad as older files though.

Ron

Ron,

I'm aware of ProjectX and also PVAStrumento. But as you noted, they have limited compatibility. None of my HBO, Starz recordings work in ProjectX because of the telecine issue. I'm not sure about PVAStrumento because it just hangs/crashes on most of my files. Looking at the log, it seems to be looking for GOP headers. I think I'll add GOP header insertion as another repair option since there seem to be many tools that assume their presence. I'll take a look at your xport source to see how you implemented that feature.

As for the remaining 169time issues... I almost always remux everything I record after I edit. That's why I need the a/v sync fix. Since I have not done much with audio, it's taking me some time to figure it all out. There's also various formats to deal with (AC3, mpeg1, AAC, etc.). I'll probably limit this feature to AC3 for now.

Any chance you could add this feature to xport? Many people just need a proper demuxer (that maintains sync with errors) so I'm sure it would be very useful.

-Mark

Hi Mark,
Thanks for a great utility, I just did a donation to show my appreciation. I find it helps TheaterTek2.0 software playback on those troubled captures where it would otherwise lock-up.

I prefer to archive to DVD-R before any repair, because I'm assuming I'll be on HD DVD media within a year or so, or a monster media server. It also ensures a repair issue won't effect my archiving.

Q: Multi-DVD source files?
Is there a way I can get mpeg2repair to read continuation .TS files off of second, third and fourth discs, swapping during repair without using something like NULLpacketSaver to read and merge on to hard disk first?

This would cut down pre-play time as the cpu intensive repair can be done while the DVD-R's are read.

Thanks again,
Rob. (registrations@largedata)

Originally posted by RobScreene
Hi Mark,
Thanks for a great utility, I just did a donation to show my appreciation. I find it helps TheaterTek2.0 software playback on those troubled captures where it would otherwise lock-up.

I prefer to archive to DVD-R before any repair, because I'm assuming I'll be on HD DVD media within a year or so, or a monster media server. It also ensures a repair issue won't effect my archiving.

Q: Multi-DVD source files?
Is there a way I can get mpeg2repair to read continuation .TS files off of second, third and fourth discs, swapping during repair without using something like NULLpacketSaver to read and merge on to hard disk first?

This would cut down pre-play time as the cpu intensive repair can be done while the DVD-R's are read.

Thanks again,
Rob. (registrations@largedata)

Thanks for the donation. I'm in this as a hobby and it feels good to know that people actually care enough to donate. It's the only way I know that anyone is actually using any of my programs.

What you suggest is possible in theory. The progress bar/status updates would need to be changed though since there would be no way to know the total length in advance. I'll try to add an option for users who need this feature and are willing to live without correct progress indicator.

I mostly use the error scan/log function and leave repair disabled. Since most channels repeat their HD programming, it helps me quickly check if a recording is good enough to keep or should be captured again. Sometimes I also use the logs as a guide to edit/combine multiple recordings that have errors in different locations.

The repair function was added mostly for other users, especially those with 169time gear running older firmware. In that specific instance, the errors were very minor and could be repaired with little or no visual impact. Final results would play much smoother in most software decoders. For sources with more severe corruption, you probably won't see much visual improvement but at least it should keep your decoder from crashing. Hopefully I can improve the repair quality in the future.

-Mark

I just purchased a r5000 unit and intend to use a myhd card for playback. Will your utility be helpful to me? I also have some dvhs tapes from 169 time that I might consider transferring into my computer. I have limited computer skills and don't want to get over my head

Originally posted by flabingo
I just purchased a r5000 unit and intend to use a myhd card for playback. Will your utility be helpful to me? I also have some dvhs tapes from 169 time that I might consider transferring into my computer. I have limited computer skills and don't want to get over my head

I would only use it to check for errors on your R5000 recordings. When you find errors, you can visually verify them to see if you still want to keep the recording. No need for repair in your case.

For old 169time recordings (pre C6 software), repair would help you run them on PC software players like WinDVD, etc. If you only play on DVHS deck then there's no point using my utility.

-Mark

Thanks for your help. I want to try to transfer some tapes from the jvc30000 to my hard drive

Hello, I just downloaded mpeg2repair to try it out, but it crashes upon startup for me. Win XP SP2, yes I have the required dlls. I can send you the crash log if needed. This is pretty much a stock system. Thanks.

I'm using MPEG2Repair to correct some bad recordings I have. It works most of the time but I have some weird things that occur.

For example, I have a recording which doesn't play well. When I run it through MPEG2Repair , the log just tells me :

MPEG2Repair: F:\nemo\Finding Nemo.0000.ts


Sequence Frame 53586(165-P) / Time 0:37:07 :
Error: Invalid motion vector code. MBA=769(784,96)
Additional error(s) detected. Increase VerboseLogLevel in INI file for details.
FileInfo: Last errors span 2 bytes at file offset 3214950210

Sequence Frame 53587(165-P) / Time 0:37:07 :

Info: End of sequence: 1920 x 1080, 29.97 fps (with telecine flags), 38.81 Mbps.
Info: Found 53587 frames/fields since start of sequence.
Info: 1 frames/fields found with errors.
Info: 2 corrupted bytes in file.

End of Log

So just a small error at 37:07 !!! As the 5 first minutes of this recording are really terrible (like a glitch every 15 seconds, jerky image, sound and image not sync for a few seconds then sync again then not, apparition of previous frames from time to time...), I would have expected MPEG2Repair to discover a lot of problems.

Would it be possible to send you those five first minutes in order to see if MPEG2Repair is missing something or if my player (MyHD) just doesn't like some foreign recording ?

Thank you,

J.

Originally posted by Johnny Begood

So just a small error at 37:07 !!! As the 5 first minutes of this recording are really terrible (like a glitch every 15 seconds, jerky image, sound and image not sync for a few seconds then sync again then not, apparition of previous frames from time to time...), I would have expected MPEG2Repair to discover a lot of problems.
J.

Sounds like the file is not properly muxed. It should contain null packets and run at constant bitrate. Anything else is never guaranteed to work on all hardware and software decoders.

My tool only verifies that the video content inside the file has no errors. It doesn't check or repair muxing issues such as decoder under/over-flow. To repair those, you'll have to demux/remux your audio/video files. If it's not too badly damaged, you may also have some luck with TStoATSC.

Try playing it on something other than MyHD. If it works, then you know it's a muxing problem.

-Mark

P.S. If anyone has a problem with MPEG2Repair Beta expiring, please download it again.

Originally posted by Wizziwig
Sounds like the file is not properly muxed. It should contain null packets and run at constant bitrate. Anything else is never guaranteed to work on all hardware and software decoders.

My tool only verifies that the video content inside the file has no errors. It doesn't check or repair muxing issues such as decoder under/over-flow. To repair those, you'll have to demux/remux your audio/video files. If it's not too badly damaged, you may also have some luck with TStoATSC.

Try playing it on something other than MyHD. If it works, then you know it's a muxing problem.

-Mark

P.S. If anyone has a problem with MPEG2Repair Beta expiring, please download it again.

You are definitevely right here. I tried with BS player and Elecard and it worked very well (except for my PC which is a little too slow for soft decoding). I have also tried with an older version of MyHD and it worked a lot better even if it wasn't perfect.

Then I guess that MyHD really doesn't like non constant bitrate recording.

Does anybody know a way to recreate a constant bitrate stream (is that the 'muxing' you're reffering to ??)

Thanks,

J.

PS : do you have a paypal account ?

Originally posted by Johnny Begood
You are definitevely right here. I tried with BS player and Elecard and it worked very well (except for my PC which is a little too slow for soft decoding). I have also tried with an older version of MyHD and it worked a lot better even if it wasn't perfect.

Then I guess that MyHD really doesn't like non constant bitrate recording.

Does anybody know a way to recreate a constant bitrate stream (is that the 'muxing' you're reffering to ??)

Thanks,

J.

PS : do you have a paypal account ?

Muxing is short for multiplexing. This is the process of combining an elementary mpeg2 video stream with an elementary audio stream (AC3 Dolby Digital) into a constant bitrate transport stream. For ATSC HDTV in the U.S., this birate needs to be ~19.4 Mbps. Many decoders need this constant bitrate in order to properly maintain time synchronization, buffer management, perform random seeking, etc. Any transport file that doesn't contain null packets and runs at variable bitrate is technically broken and not guaranteed to work in all players.

If your file isn't too far out of spec, you may be able to restore it to constant bitrate with the TSToATSC or TSToATSC3 utilities. Search the forums or the MPEG2Repair FAQ for details. Other methods would be to use commercial muxing software like transmux or mp2tsms.

There are paypal links at the bottom of the mpeg2repair homepage for anyone wishing to donate to the project.

http://users.adelphia.net/~mwilczyn/mpeg2repair/

P.S. Version 1.0.0.9 is currently in final testing. Barring any last minute bugs, it should be out sometime today.

169time records to PC, repaired thru the tool, enabled NullStrip, the output file is much smaller, played fine with zoomplayer(Elecard codec)...but MyHD take more than 1 minute to load the file...after loading, playing is fine, time stamp was off though...what's the problem (before null strip, MyHD player ok)...so the problem is obviously the nullstripper, any idea to fix this?

By the way, is there a recommended ini settings? Can't find any info explains the config entries of ini...

Originally posted by WoodyT
169time records to PC, repaired thru the tool, enabled NullStrip, the output file is much smaller, played fine with zoomplayer(Elecard codec)...but MyHD take more than 1 minute to load the file...after loading, playing is fine, time stamp was off though...what's the problem (before null strip, MyHD player ok)...so the problem is obviously the nullstripper, any idea to fix this?

By the way, is there a recommended ini settings? Can't find any info explains the config entries of ini...

As posted in my previous reply, removing null packets from a transport stream is a bad idea. The files will no longer follow the mpeg2 specs and are not guaranteed to play on all players. It's a risk you have to take if you really need to save the disk space.

There are many reasons why some files may work better than others after null packet removal. The mpeg2 payload may be encoded at a fixed bitrate, in which case removing the null packets will not cause as much of a disruption. Most content coming from cable/satellite providers is variable bitrate so keeping the null packets is more important.

Moral of the story: DON'T REMOVE NULL PACKETS!. If you're really desperate for disk space, either compress your transport files or backup the null packets with my NullPacketSaver tool.

I actually never had any problems removing null packets before (using directx filter in dvhstools I remember)...the file is smaller, zoomplayer/WMP/MyHD all played those files flawlessly (OTA HD or dish from dish 5000+HD modulator).

Even the file I have mention above, it still can be playback, and once starting the play, it's perfect, only problem is file loading take forever. I actually already had solution for it: split the big files into small files (512M each) with HDTV2MPEG, and MyHD loads it in 3-5 seconds, which then played flawlessly...so I don't think removing null packets is risky, I have yet found any file will not play after the removal.

Wizziwig,

One more question. I had following post in 169time support forum...I have tried to repair it with your tools with no luck (I understand the 65M is not considered as an error, however, the bit rate is absolutely incorrect.)

Using dish 6000 169time, allmost all the channels shows 18Mbps, but HDnet movie shows 65Mbps...why is that? The file is played ok by MyHD, but the total time displayed was off...

Originally posted by WoodyT
Wizziwig,

One more question. I had following post in 169time support forum...I have tried to repair it with your tools with no luck (I understand the 65M is not considered as an error, however, the bit rate is absolutely incorrect.)

Using dish 6000 169time, allmost all the channels shows 18Mbps, but HDnet movie shows 65Mbps...why is that? The file is played ok by MyHD, but the total time displayed was off...

Please keep in mind that the bitrate reported at the end of the log file comes directly from the mpeg2 sequence header. It's up to the signal provider (HDNet in this case) to make sure it's reasonable. The other channels you mentioned are re-encoded by Dish Network so they force the sequence headers to 18 Mbps. HDNet sets the sequence header bitrate to all sorts of values - I've seen 45, 65, and 80. In reality none of this matters because this value is not used during decoding. It's purely for informational purposes.

If you want to get a rough idea of the actual bitrate, you'll have to run the file through something like TSReader and look at the green bar graphs for your audio/video PID.

As for why the total time may be wrong, there are many possibilities. The file may have been edited in an editor that doesn't correctly update timestamps. There may also be a time-stamp reset/wrap-around during the transmission. These resets always occur approximately every 26 hours so if you do a lot of recording, you'll probably see one sooner or later.

There is an alternate method to calculate time which works for all cases (including edits), but I have not had the time to get it implemented. Maybe in next version. Until then, you can also use the number of total frames as a good indicator of file length. Just remember that anything with telecine/repeat flags will actually run at about 23.976 fps, not 29.97.

-Mark

Originally posted by WoodyT
I actually never had any problems removing null packets before (using directx filter in dvhstools I remember)...the file is smaller, zoomplayer/WMP/MyHD all played those files flawlessly (OTA HD or dish from dish 5000+HD modulator).

Even the file I have mention above, it still can be playback, and once starting the play, it's perfect, only problem is file loading take forever. I actually already had solution for it: split the big files into small files (512M each) with HDTV2MPEG, and MyHD loads it in 3-5 seconds, which then played flawlessly...so I don't think removing null packets is risky, I have yet found any file will not play after the removal.

WoodyT

Try last beta version of MyHD (1.64.something - the one that allows timeshifting). It works a lot better with non CBR streams and the long pause just disappears (at least for me and for some recordings I've tried).

J.

PS : @Wizziwig : J. = Neo, for this great utility.

Originally posted by Wizziwig
Muxing is short for multiplexing. This is the process of combining an elementary mpeg2 video stream with an elementary audio stream (AC3 Dolby Digital) into a constant bitrate transport stream. For ATSC HDTV in the U.S., this birate needs to be ~19.4 Mbps. Many decoders need this constant bitrate in order to properly maintain time synchronization, buffer management, perform random seeking, etc. Any transport file that doesn't contain null packets and runs at variable bitrate is technically broken and not guaranteed to work in all players.

If your file isn't too far out of spec, you may be able to restore it to constant bitrate with the TSToATSC or TSToATSC3 utilities. Search the forums or the MPEG2Repair FAQ for details. Other methods would be to use commercial muxing software like transmux or mp2tsms.


Thanks for this info. But it's now getting too much time consuming for me to process those files. I'd rather try to find good untouched and CBR sources for my streams ;-))

J.

Great info, I will try that. Thanks a lot!

Originally posted by Johnny Begood
WoodyT

Try last beta version of MyHD (1.64.something - the one that allows timeshifting). It works a lot better with non CBR streams and the long pause just disappears (at least for me and for some recordings I've tried).

J.

PS : @Wizziwig : J. = Neo, for this great utility.

New version (1.0.0.9) of MPEG2Repair is now available. Lots of user-requested improvements. Make sure you read the included readme and changelog files to understand the new features. Of specific interest to heavy users, there are now ways to pause the program and reduce CPU usage when multi-tasking.

Enjoy!

-Mark

Johnny ,

It worked...now only the display time is off, I can live with that, not a big deal (a 2 hours movie displayed as 1 hour or so, actually playing is not affected). Thank you so much..

I will be trying new MPEG2Repair too, it's a great tool, thanks Wizziwig

Wizziwig,

I see. So this also explains why even if I turn on null strip, it doesn't remove too much from HDNET or HDNET Movie files, these are really full rate transmission, am I right? Thanks.

Originally posted by Wizziwig
Please keep in mind that the bitrate reported at the end of the log file comes directly from the mpeg2 sequence header. It's up to the signal provider (HDNet in this case) to make sure it's reasonable. The other channels you mentioned are re-encoded by Dish Network so they force the sequence headers to 18 Mbps. HDNet sets the sequence header bitrate to all sorts of values - I've seen 45, 65, and 80. In reality none of this matters because this value is not used during decoding. It's purely for informational purposes.

If you want to get a rough idea of the actual bitrate, you'll have to run the file through something like TSReader and look at the green bar graphs for your audio/video PID.

As for why the total time may be wrong, there are many possibilities. The file may have been edited in an editor that doesn't correctly update timestamps. There may also be a time-stamp reset/wrap-around during the transmission. These resets always occur approximately every 26 hours so if you do a lot of recording, you'll probably see one sooner or later.

There is an alternate method to calculate time which works for all cases (including edits), but I have not had the time to get it implemented. Maybe in next version. Until then, you can also use the number of total frames as a good indicator of file length. Just remember that anything with telecine/repeat flags will actually run at about 23.976 fps, not 29.97.

-Mark

Originally posted by WoodyT
Wizziwig,

I see. So this also explains why even if I turn on null strip, it doesn't remove too much from HDNET or HDNET Movie files, these are really full rate transmission, am I right? Thanks.

Yes. On Dish Network, HDNet broadcasts at a constant bitrate of around 18 Mbps. This only leaves a small amount of non-essential data that you can remove. The other channels are variable bitrate and change constantly from 5-17 Mbps depending on what's going on in the program and on other channels sharing the same transponder.

if it hasn't been noted already, in the new 1.0.0.9 beta

press Find PIDS on a ts file that has multiple program streams
click Repair checkbox and enter repair file name
[optional] click Log checkbox and enter log file name

change Program number in combobox

all the entry fields and checkboxes clear, going back to blank and losing all the work
prior software versions entered data when changing the program number
no doubt due to the new code to auto-enter text fields

as always, thx for your hard work

Yes, great job as usual. I just donated!

Here's a clip that crashes MPEG2Repair (at least with the older version, when I tried it) The clip is garbage, as far as I can tell. I have no idea how it got corrupted.

http://www.eecs.umich.edu/~balazer/mpeg2repair_bad/

Originally posted by ctmooregottapee
if it hasn't been noted already, in the new 1.0.0.9 beta

press Find PIDS on a ts file that has multiple program streams
click Repair checkbox and enter repair file name
[optional] click Log checkbox and enter log file name

change Program number in combobox

all the entry fields and checkboxes clear, going back to blank and losing all the work
prior software versions entered data when changing the program number
no doubt due to the new code to auto-enter text fields

as always, thx for your hard work

Yeah, you're right. That's part of the GUI changes in last version. When you select a different input file or change any of the input options (like program and/or audio/video track) it resets the program to the initial state. It's not really a bug. I did this to prevent users from accidentally overwriting their previous scan/repair. There's also some confirmation dialog boxes but I figured doing a reset would be even safer.

Originally posted by balazer
Here's a clip that crashes MPEG2Repair (at least with the older version, when I tried it) The clip is garbage, as far as I can tell. I have no idea how it got corrupted.

http://www.eecs.umich.edu/~balazer/mpeg2repair_bad/

Got it. Thanks.

-Mark

Several questions

1) You have noted in emails that .10 is available. It's not on the website. Where might it be obtained?

2) The log output used to show the number of bytes in the video frames that were bad. Now I do not see this. This helped gauging the severity of the errors. Is this available to be turned back on via the .ini files? It is sorely missed.

3) I have sent you via email a video segment that blows up the program and shuts it down. I have gotten no confirmation that you have received this. Did you or has your spam checker grabbed it?

Thanks.

Why has this thread gone silent

Like HDTVFanAtic said is there a .10 available - This is a great tool - I just hope it does not die....

I have found this tool to be absolutely indispensable but it is quite common on larger .ts files (8GB and up) to find it get about 80% finished and then crash.

I heard some talk about a .10 being released, is that true? Has any of this kind of stuff been fixed?

Thanks for the great tool Mark, saved my ass a few times!

I have found this tool to be absolutely indispensable but it is quite common on larger .ts files (8GB and up) to find it get about 80% finished and then crash.

I heard some talk about a .10 being released, is that true? Has any of this kind of stuff been fixed?

Thanks for the great tool Mark, saved my ass a few times!

Please send the repair log and a short clip if possible (around the point where it crashed) to mpeg2repair@adelphia.net. You can use a tool like HDTVtoMPEG2 to make the sample (make it 1-3 MBytes). Run the sample through my tool to make sure it still crashes. Version .10 has not been publicly released. Most likely your error has already been fixed but I can always use more clips to test against.

FYI : A new version will come out eventually... Now that E3 is over and my video game project is wrapping up, I should have some free time to work on this tool again in a month or so.

-Mark

thanks mark!!!!

I have recorded Stigmata off E* HDNET feed 4 times now. At literally the same place in every feed MPEG2REPAIR errors with a problem it wants to report to Microsoft. Can you please forward a copy of the .10 Beta so I may try it on the 3TB of files I have that MPEG2REPAIR errors on?

Also reports Canadian Cable feeds that are 1920x1080i in headers with every other program as 1440x1080i.

Wizzywig,

Just wanted to let you know how much I value your tool, and your hard work and effort here. Your tool is really a custom piece of software for all of us HDNuts, and I hope others have shown you how much they value your efforts here. Keep up the great work!

Alex

PS: Quick question. I have heard that on some relevant TS's, running repair could do more harm than good on the file. Is this true? Some have said to do a scan 1st, but a scan takes just as long (almost, at least) as the repair, and running scan and then repair = ~ twice as long. Why not just always run the repair (assuming you have the HDD space buffer), and then discard the repaired versions if there are problems? Or look at the scan or repair error log to determine which version to use. Can you give some guidance on when to be wary of using this tool? Thanks again for all your hard work!
:)

Wizzywig,
PS: Quick question. I have heard that on some relevant TS's, running repair could do more harm than good on the file. Is this true? Some have said to do a scan 1st, but a scan takes just as long (almost, at least) as the repair, and running scan and then repair = ~ twice as long. Why not just always run the repair (assuming you have the HDD space buffer), and then discard the repaired versions if there are problems? Or look at the scan or repair error log to determine which version to use. Can you give some guidance on when to be wary of using this tool? Thanks again for all your hard work!
:)

Unless you're low on disk space, it's probably best the just do the repair. Then using the log, you can compare the areas with errors to see if you prefer the original or repaired file. My tool should not harm or change any areas that don't have errors. Be careful though if your recording is spliced together from streams using different PID mappings. You might end up losing those parts of the file. I've heard of this happening on commercial breaks for some stations. If you have an example of this, please let me know and I'll try to address it in a future version.

You really need to check things for yourself because each player handles errors in a different way. Some players may be able to recover from errors in a cleaner way than my tool. Others may freeze/skip on errors so my tool could be useful if you would like to see those parts of the recording (even at degraded quality).

I finally have some time to work on this tool again and plan to release a new version sometime next week. It will fix most of the crashes that were introduced in the last version when I added the AC3/audio error-checking.

-Mark

1) Next version is still on track for release within a week or so. Currently working on a way to restore a/v sync to files with dropped audio and/or video frames. It's a really tricky problem. Hopefully once I get it working, we'll be able to demux and remux files with drop-outs and still maintain proper a/v sync. If anyone knows of another method/tool to do this, please let me know. It would be helpful for verifying my results.
-Mark

How is progress on this front? I've been converting some TS files over to XviD and the video stream errors are killing the a/v sync. Some way to "fix" this in the source would be great.

How is progress on this front? I've been converting some TS files over to XviD and the video stream errors are killing the a/v sync. Some way to "fix" this in the source would be great.

New version was posted today (1.0.1.0). There is no practical way to fix A/V sync problems without demuxing/remuxing the audio/video streams. That's beyond the scope of my tool.

I suggest checking out the stream repair feature in VideoRedo or ProjectX. Those programs don't fix errors in the mpeg2 payload but they will remux them for you and remove parts with a/v sync problems.

With some experience, you could also use the logs from my tool to manually resync the files after demuxing. Just compare the size of the audio/video gaps at each desync and adjust the audio track to compensate. Maybe someday I'll release a TS demuxer that does this automatically.

-Mark

Thanks. ProjectX just says every frame is bad. I'm trying VideoRedo but seems as if I may have discovered a bug and they are looking in to it.

Use your log file and adjust the audio track? Are you saying to use some kind of ac3 editor and make small slices trying to remove the same amount of audio as is missing video?

Wouldn't there be some way to "fill" in the missing video data? Like with just black? I would be happy with tiny scenes that just went black if the audio remained sync'd for the rest of the movie.

Or how about just inserting the previous good frame where one is missing/bad?

btw - I wouldn't care that the ts would have to be demuxed.

Thanks. ProjectX just says every frame is bad. I'm trying VideoRedo but seems as if I may have discovered a bug and they are looking in to it.

Use your log file and adjust the audio track? Are you saying to use some kind of ac3 editor and make small slices trying to remove the same amount of audio as is missing video?

Wouldn't there be some way to "fill" in the missing video data? Like with just black? I would be happy with tiny scenes that just went black if the audio remained sync'd for the rest of the movie.

This is really getting too technical for this forum, but what I was suggesting is to demux the transport file after running it through my program. You then have an MPEG2 elementary stream and AC3 audio file. Each file will be slightly different time length because of the gaps/errors.

The MPEG2 data can't be frame edited because of the dependency between frames. But the audio data is easy to change since each frame is independent of the rest. Most of the recordings out there use AC3 frames of 1536 bytes where each frame starts with 0x0b77 and lasts 0.032 seconds. So using the repair logs, you locate the corrupted audio frame and copy/paste another 1536 byte frame over it. You can also insert a copy of the previous 1536 byte frame if you need to decrease the size of the audio gap or cut 1536 bytes to increase the size of the audio gap. Do whatever is needed to make the audio gap match the video gap size. Since the gaps won't be an exact multiple of 0.032 seconds, keep track of any remainder/overflow as you go through the file and add it back to the next desync point to compensate.

I would just do this with a Hex editor but it's really not something practical for a novice.... Someone would need to write a demuxing tool to do this automatically. That's what ProjectX was supposed to do but I guess it's not compatible with your specific file. VideoRedo is probably your best bet for now since the author is very responsive in trying to improve the program.

-Mark

HookedOnTV,

I discovered a very practical and FREE way to help fix these A/V out of Sync errors.
The free program is YAAI (acronym for Yet Another Avi Info), and with it, you have instant A/V feedback for stretching and compressing audio temporally (if audio goes out of sync gradually with the video), adding a delay to audio or video (if the lip sync delay amount seems constant), or both (if you have constant delay and (which) becomes worse over time). After using it a few times, you will become an expert. And you can use this on your already encoded XviD's (works on any *.avi). If your Vidomi made a *.divx, just choose All Files when using YAAI to open, and you will find the *.divx, *.xvid, or whatever. Or just rename your divx or xvids to *.avi. YAAI works like a charm, and it is free. Get it here:

http://www.softpedia.com/get/Multimedia/Video/Encoders-Converter-DIVX-Related/YAAI-Yet-Another-Avi-Info.shtml

Granted, this is a Band-Aid fix, but for people who aren't snobby gurus, this fix works. And BTW, I had to learn this all on my own. There is some predictable taboo against providing any easy fix or practical help to anyone who asks. Never ask an expert a question – you will get a technical teaser, and nothing practical. I have made it my mission to be the opposite, and to offer practical advice when asked (see my Vidomi guide).

Also, you may find Windows won't let you delete/rename your avi's, so you will have to make a modification to your registry. Practical details here: http://cdrlabs.com/phpBB/viewtopic.php?p=119088&sid=751856abc9699a02ec508983b2198fca

This should solve your problems! Best of luck to you ;)

Finally we all owe Mark (Wizzywig) a huge debt of gratitude. Without his tool, many of these re-codes would choke the encoder and fail half way through the encoding process.

Thus far I have yet to hit a cap where the new version errored out.

From the 5 caps of Stigmata that all blew the previous problem up, I believe this was the issue:


Sequence Frame 27419(14-P) / Time 0:15:14 :
AudioError: Corrupted AC3 frame of 3074 payload bytes at file offset 2106620172
AudioWarning: Timestamp gap of -22006.929634 sec. ending at file offset 2106620172
AudioError: Corrupted AC3 frame of 3070 payload bytes at file offset 2106704772

Sequence Frame 27421(13-B) / Time 0:15:14 :
AudioError: Corrupted AC3 frame of 30388 payload bytes at file offset 2106724332
AudioWarning: Timestamp gap of 22006.897634 sec. ending at file offset 2106724332

When it went that far negative, I assume the program choked. As it is in all 5 showings that HDNET did, I guess it must be in the master that way?!?!?!?

Very nice work.

Now if I can only figure out what this is or what it means:

Sequence Frame 73389(12-B) / Time 0:40:48 :
VideoWarning: DMV motion prediction not supported in MPEG2Repair. MBA=3334(1504,432)
VideoError: Invalid frame_motion_type for macroblock. MBA=3335(1520,432)
VideoError: Failed to decode macroblock at MBA=3335(1520,432)
VideoError: Missing 1 picture slices at MBA=3334(1504,432)

HookedOnTV,

I discovered a very practical and FREE way to help fix these A/V out of Sync errors.
The free program is YAAI (acronym for Yet Another Avi Info), and with it, you have instant A/V feedback for stretching and compressing audio temporally (if audio goes out of sync gradually with the video), adding a delay to audio or video (if the lip sync delay amount seems constant), or both (if you have constant delay and (which) becomes worse over time). After using it a few times, you will become an expert. And you can use this on your already encoded XviD's (works on any *.avi). If your Vidomi made a *.divx, just choose All Files when using YAAI to open, and you will find the *.divx, *.xvid, or whatever. Or just rename your divx or xvids to *.avi. YAAI works like a charm, and it is free. Get it here:

http://www.softpedia.com/get/Multimedia/Video/Encoders-Converter-DIVX-Related/YAAI-Yet-Another-Avi-Info.shtml

Granted, this is a Band-Aid fix, but for people who aren't snobby gurus, this fix works. And BTW, I had to learn this all on my own. There is some predictable taboo against providing any easy fix or practical help to anyone who asks. Never ask an expert a question – you will get a technical teaser, and nothing practical. I have made it my mission to be the opposite, and to offer practical advice when asked (see my Vidomi guide).

Also, you may find Windows won't let you delete/rename your avi's, so you will have to make a modification to your registry. Practical details here: http://cdrlabs.com/phpBB/viewtopic.php?p=119088&sid=751856abc9699a02ec508983b2198fca

This should solve your problems! Best of luck to you ;)

Finally we all owe Mark (Wizzywig) a huge debt of gratitude. Without his tool, many of these re-codes would choke the encoder and fail half way through the encoding process.

Thanks for the suggestion, I may try it out. I have got VideoRedo working and it is solving my problems wonderfully. It is simple to use and for the most part completely automated (select input file, select output file and fix). Downside is of course that it isn't free but after taking a look at what would be involved in coding up my own application it might be worth it.

Now if I can only figure out what this is or what it means:

Sequence Frame 73389(12-B) / Time 0:40:48 :
VideoWarning: DMV motion prediction not supported in MPEG2Repair. MBA=3334(1504,432)
VideoError: Invalid frame_motion_type for macroblock. MBA=3335(1520,432)
VideoError: Failed to decode macroblock at MBA=3335(1520,432)
VideoError: Missing 1 picture slices at MBA=3334(1504,432)
I believe MPEG2Repair is reporting that it doesn't support dual-prime motion vectors (DMV). Dual-prime is a special mode that's typically only used for low-delay bitstreams (that do not contain B-frames).

Since this error happened in a B-frame, it's not a real dual-prime vector. The bad bits just happened to end up signalling dmv=1.

Ron

I believe MPEG2Repair is reporting that it doesn't support dual-prime motion vectors (DMV). Dual-prime is a special mode that's typically only used for low-delay bitstreams (that do not contain B-frames).

Since this error happened in a B-frame, it's not a real dual-prime vector. The bad bits just happened to end up signalling dmv=1.

Ron

Yup.. Ron is correct. The decoder used in my tool currently doesn't support DMV motion prediction. Most of my work required lots of trial-and-error coding and testing on all the available HDTV sources. Since I never ran into a single legitimate example that used DMV, I never bothered to code it. I also don't support field coded pictures (in case anyone cares) since everything I've seen so far uses frame pictures.

So the warning in your log is not really DMV usage but an error that corrupted the bits in such a way as to appear like DMV. Just treat it like any other error. You will see that the warning is usually followed by another error since the rest of the macroblock is also corrupted.

One note for anyone using VideoRedo. It's been brought to my attention that this editor may use DMV when re-encoding for frame-accurate editing. For such cases, ignore this warning or change the options in VideoRedo so that it edits on GOP boundaries instead of exact frames.

-Mark

One note for anyone using VideoRedo. It's been brought to my attention that this editor may use DMV when re-encoding for frame-accurate editing. For such cases, ignore this warning or change the options in VideoRedo so that it edits on GOP boundaries instead of exact frames.



I know a number of VideoRedo users were wondering if the errors they saw after using VideoRedo were real or not.

Does this answer mean that the errors are real in the VideoRedo corrected file - or just that VideoRedo is outputing DMV files and mpeg2repair is seeing an error and just doesn't support dmv to correct it?

I know a number of VideoRedo users were wondering if the errors they saw after using VideoRedo were real or not.

Does this answer mean that the errors are real in the VideoRedo corrected file - or just that VideoRedo is outputing DMV files and mpeg2repair is seeing an error and just doesn't support dmv to correct it?

Yes. VideoRedo works fine. It's a limitation of my program. VideoRedo is simply generating MPEG2 files using a feature I don't support in my tool. They are perfectly valid and will play in all MPEG2 decoders. Ignore the warnings if they occur in places where VideoRedo has re-encoded the video.

Someday I'll try to add DMV to my tool... it just hasn't been high priority because it's not commonly used for real world MPEG2 HDTV delivery. Our resident MPEG2 expert dr1394, confirmed it. :)

Most every capture that I had that previously produced an error runs perfectly under the new software. Thanks.

The only exception is a new capture I have that I don't know how to proceed - as I am trying to get you a sample....but read on....

The repair stops at 61% and want to send an error to Microsoft.

I have tried to clip out 10 seconds around the error - unfortunately, it doesn't error out when I run a small sample. I thought I had missed the error.

I then took the 10GB capture and cut it into (4) 2.5GB pieces.

MPEG2REPAIR runs fine on all seperate pieces.

I have even run MPEG2REPAIR on the 4 pieces that were previously run seperately through MPEG2REPAIR and it creates a 10GB file with no error.

I have replicated this twice on 2 different machines.

Here is the log from the 3rd piece. I assume the errors around 11:38 is what is causing the issue:

Sequence Frame 10903(24-B) / Time 0:03:01 :
AudioWarning: Timestamp gap of 0.008878 sec. ending at file offset 282346200

Sequence Frame 41862(2-I) / Time 0:11:38 :
AudioError: Corrupted AC3 frame of 1534 payload bytes at file offset 1083862948

Sequence Frame 41870(7-B) / Time 0:11:38 :
Error: Failed parsing PES PTS Bits 29...0
AudioError: Corrupted AC3 frame of 2607 payload bytes at file offset 1084067876

Sequence Frame 41871(11-P) / Time 0:11:38 :
AudioError: Corrupted AC3 frame of 2001 payload bytes at file offset 1084118845

Sequence Frame 41880(20-P) / Time 0:11:38 :
AudioError: Corrupted AC3 frame of 58336 payload bytes at file offset 1084131044
AudioWarning: Timestamp gap of 0.128000 sec. ending at file offset 1084131044

Sequence Frame 83473(24-B) / Time 0:23:12 :
AudioWarning: Timestamp gap of 0.008878 sec. ending at file offset 2160867768

Sequence Frame 99621(28-B) / Time 0:27:41 :

Info: End of sequence: 1280 x 720, 59.94 fps, 65.00 Mbps.
Info: Found 99621 video frames since start of sequence.
Info: 0 video frames found with errors.
Info: 4 audio frames found with errors.
Info: 0 corrupted video bytes in file.
Info: 0.000000 seconds of video timestamp gaps.
Info: 0.145756 seconds of audio timestamp gaps.

Do you see anything there that would cause an issue when the complete file is run - but not when it is in pieces? I'm clearly scratching my head.

Sequence Frame 41880(20-P) / Time 0:11:38 :
AudioError: Corrupted AC3 frame of 58336 payload bytes at file offset 1084131044
AudioWarning: Timestamp gap of 0.128000 sec. ending at file offset 1084131044

Do you see anything there that would cause an issue when the complete file is run - but not when it is in pieces? I'm clearly scratching my head.

The error above is the one causing the crash. It's overflowing an internal buffer and corrupting memory in unpredictable ways. I'll try to do a quick patch tonight and post a new version.

Also reports Canadian Cable feeds that are 1920x1080i in headers with every other program as 1440x1080i.

Someone also emailed me a sample that reports this wacky resolution you mentioned before. It will actually get reported as:

1920 x 1080(1440 x 1080 Display)

This means that the sequence header says 1920x1080 (this is what most other programs use) but the sequence header extension for display size says 1440x1080. This is a hint to the decoder telling it to crop the frame and only display 1440x1080. Luckily most/all decoders will just ignore this and display the entire 1920x1080 frame. Normally the extension is set to 1920x1080 so that the decoder will not display a full 1920x1088 frame because the bottom 8 rows are garbage. Looks like a bug in the encoder used by this satellite/cable company.

On the same recording, I also noticed that the encoder sometimes produces motion vectors that reference -0.5 pixels off the left edge of the screen. Shows up as errors at x-coordinate 0 in my logs. I ran this sample on a couple of my players and they all seem to accept these minor out-of-bounds motion prediction errors. I guess there is some guard-band allowed by the standard. I'm going to add an option to my tool to ignore these minor motion vector errors since repair makes them look much worse and they work perfectly on most players.

-Mark

Edit: New version is posted. Please let me know if it fixes the crash you found.

This program works great for me, it greatly improves playback of my motorola 5000 STB firewire recordings with VLC with Comcast Atlanta that have errors in the stream! Problem solved!

I would like to make a request. I would like to be able to run the program from the command line, specifying input and output files. The GUI runs and closes after completion. This would be a big help in automating execution of this program from a perl script, automatically cleaning up recordings. Any chance you could add this feature? I think others would find it useful as well.

Thanks alot!

Thank you Wizziwig for a very classy tool. I'll second that request for it to accept a command line parameter. That is, it would be very helpful if the following commandline
mpeg2repair "%1"
would start mpeg2repair with the filename %1 as the input file. That would allow you to access Mpeg2repair conveniently from the right-click menu in Windows.

Another feature request: could it allow the log and output files to be written to different hard drives from the input file? Apologies if the software does this already and I just have not figured how to do it.

Another feature request: could it allow the log and output files to be written to different hard drives from the input file? Apologies if the software does this already and I just have not figured how to do it.


all already does that....just change the drive letter in the output file and log window.

Thanks for a great program. I would like to include this program in a perl script to automate things. If you don't want to/have time to add this feature, can you post the source code? I should be able to add this feature and roll the source back into your hands...

This looks like a good thing to run on my video server at night. I will post my perl script on this forum if anyone wants to use it.

thanks,
-ck

Thanks for a great program. I would like to include this program in a perl script to automate things. If you don't want to/have time to add this feature, can you post the source code? I should be able to add this feature and roll the source back into your hands...

This looks like a good thing to run on my video server at night. I will post my perl script on this forum if anyone wants to use it.

thanks,
-ck

What do you think the chances are of getting source code to a program, which expires every few months "for liability reasons". LOL. You'd have more luck getting Windows SC than this. I don't think this program will ever be owned by anyone, free or for a price, as long as every version has Shiva built into it.

Still, great software Wizzywig. Just wish you'd be slightly loose with it. I do not believe that by you making the software not function after a certain period of time, you somehow immunize yourself from lawsuits / liability. What is the logic there, if I may ask? Just trying to understand. Is this the real reason for every version having an expiration, or is there really some other reason? Again, thanks for the great work. We look forward to the next version of this (once the current one becomes non-functional).

What do you think the chances are of getting source code to a program, which expires every few months "for liability reasons". LOL. You'd have more luck getting Windows SC than this. I don't think this program will ever be owned by anyone, free or for a price, as long as every version has Shiva built into it.

Still, great software Wizzywig. Just wish you'd be slightly loose with it. I do not believe that by you making the software not function after a certain period of time, you somehow immunize yourself from lawsuits / liability. What is the logic there, if I may ask? Just trying to understand. Is this the real reason for every version having an expiration, or is there really some other reason? Again, thanks for the great work. We look forward to the next version of this (once the current one becomes non-functional).

This program expires every free months? Dang, I didn't know that.

Maybe he's worried about the MPAA sueing him or something.

How about that command line feature dude?

This program expires every free months? Dang, I didn't know that.

Maybe he's worried about the MPAA sueing him or something.

How about that command line feature dude?

I can't get into all the reasons why I have the expiration in there on a public forum. Other people who write mpeg2 decoder/encoder related utilities probably understand the legal issues for a freeware utility like mine.

Besides the above, I also considered the dangers of a tool like this. If there were any serious bugs that got into a certain version, I wouldn't want it floating around on the internet forever. Not everyone reads this forum and they might lose some valuable/irreplaceable recordings if there were some major problem.

Having the expiration in there makes sure that people are always running the latest version. It also gives me incentive to put out a new version every few months. :)

Don't worry, if I ever do stop work on this program, I will release a version without expiration date.

-Mark

P.S. Sorry, no idea if/when command-line version will be released. I looked at adding that feature before but it's non-trivial with the way the tool is designed. Also no way to return result codes from a non-console Win32 app.

Sounds good to me.

This eliminates the fear that if/when you stop work on the program it will vanish forever once the last expiration date is reached.

Thanks again for sharing such an amazingly useful tool. It is invaluable for those who transcode OTA ATSC recordings down to DVD resolution for archival purposes.

Its a wonderfull program, Wizzywig, and as you know, I'd be happy to pay for your labor of love if and when a final version is offered for sale. In the mean time, I encourage EVERYONE who uses this nifty utility to consider donating $5-10 toward its developement. Think to your self - what would I do without this program? Is it worth a few bucks to show my appreciation? 'nuff said ;)

Thanks very much Wizzi for this program

Micro errors from HDNet Movies on Dish that cause the MyHD card to pixelate the entire screen can be reduced to a single flashing black pixel or 2 by correcting the errors

Again thanks, this is even useful for the R5000-HD which cannot work miracles with Dish's error filled HDNet Movies streams

-Gary

I have purchased VideoReDo Plus to edit commercials out of my OTA Transport Streams, and it does a mostly wonderful job of it. The only thing I haven't gotten my arms around yet is that sometimes when a capture (MDP-130) has errors in it (transmission or ?) I'm not sure that the way VRD handles them is the best way to do it, for example the video frame may freeze for a second or two.

Anyway while I've read a couple pages back about the "DMV motion protection" thing (what, something to do w/the long lines at the Department of Motor Vehicles? ;) ) I wonder if anyone here can suggest to me in simple terms why one might want to use both tools, i.e. does MPEG2Repair have any advantages over VRD+, or uses alongside it. Or maybe the answer is simply, "no, you have no practical reason to use m2r".

I have purchased VideoReDo Plus to edit commercials out of my OTA Transport Streams, and it does a mostly wonderful job of it. The only thing I haven't gotten my arms around yet is that sometimes when a capture (MDP-130) has errors in it (transmission or ?) I'm not sure that the way VRD handles them is the best way to do it, for example the video frame may freeze for a second or two.

Anyway while I've read a couple pages back about the "DMV motion protection" thing (what, something to do w/the long lines at the Department of Motor Vehicles? ;) ) I wonder if anyone here can suggest to me in simple terms why one might want to use both tools, i.e. does MPEG2Repair have any advantages over VRD+, or uses alongside it. Or maybe the answer is simply, "no, you have no practical reason to use m2r".

I'm not an expert on the program, but I think VRD will only be useful at repairing timestamp errors. These are caused by missing audio/video frames. It's a very nice feature and something that MP2R does not repair (although it will report in the logs). Without fixing these sorts of errors, it's very difficult to demux or convert your file to another format without introducing lip-sync problems.

I'm guessing that VRD fixes those problems by repeating frames to fill in the gaps or simply cuts out the sections with the gaps. If it repeats frames, you will end up seeing some freezes/pauses while the audio continues. If this bothers you, maybe you can ask the author to add an option that removes bad sections instead.

MPEG2Repair was designed mostly to fix errors within frames (not missing frames). So if you have a partially corrupted frame, my tool can be useful at cleaning it up slightly. Whether it's an improvement or not will depend largely on your decoder. Some are better at dealing with errors than others.

Even if you're not doing repair, my tool is a great time saver if you're recording from channels that frequently repeat their programming (like most premium movie channels). You can quickly find out whether you got a clean recording or need to try again. Without this program, you would need to watch the entire show to verify if there were any errors.

-Mark

Many thanks Mark for your complete & thoughtful reply. I think you're exactly right about the lip-sync situation; VRD+ does always maintain perfect lipsync, even when there are horrible glitches in the transmission...it always somehow makes it back to play well again. It does also have a couple options for "adding video" or "cutting audio" to do this--I have to play with it some more.

Even if you're not doing repair...You can quickly find out whether you got a clean recording or need to try again. Without this program, you would need to watch the entire show to verify if there were any errors.Hmm, I'm glad I asked--I would not have thought to use your program to only look at the log file for errors.

Thanks again! :)

I capture HDV video from my Sony HDR-HC1 with capdvhs and I can write the video back to another tape without problems. If I run the file through mpeg2repair I cannot write the file to tape. The Sony just shows a blue screen. I have tried other capture and recording programs but none of them will write a repaired file. I also have tried various settings in the ini file and the problem persists.

I capture HDV video from my Sony HDR-HC1 with capdvhs and I can write the video back to another tape without problems. If I run the file through mpeg2repair I cannot write the file to tape. The Sony just shows a blue screen. I have tried other capture and recording programs but none of them will write a repaired file. I also have tried various settings in the ini file and the problem persists.
Why would you even bother with MPEG2Repair? Your CapDVHS captures from your
HC1 should already be error free.

To Wizziwig:
If you're still interested, I have some field based test bitstreams for you. I have
one bitstream with just field structure and another with the works (dual-prime,
16x8 and progressive refresh).

Ron

I capture HDV video from my Sony HDR-HC1 with capdvhs and I can write the video back to another tape without problems. If I run the file through mpeg2repair I cannot write the file to tape. The Sony just shows a blue screen. I have tried other capture and recording programs but none of them will write a repaired file. I also have tried various settings in the ini file and the problem persists.


As Ron/dr1394 said - it probably isn't needed - but if I had to speculate, mpeg2repair is taking out the filler bytes that the HC-1 most likely needs. Trying editting the .ini to have it not nullstrip.

Why would you even bother with MPEG2Repair? Your CapDVHS captures from your
HC1 should already be error free.

To Wizziwig:
If you're still interested, I have some field based test bitstreams for you. I have
one bitstream with just field structure and another with the works (dual-prime,
16x8 and progressive refresh).

Ron

Sorry I haven't checked this thread in a few days...

My guess is that the HC1 requires some additional data to be present in the transport file. My program will normally strip out (or replace with null packets) everything but the 4 required PID's (PAT, PMT, Video, and Audio) necessary to play on most players. The HC1 may also be expecting data on fixed PID assignments and ignoring the PAT/PMT. I'll try to add some options on next version to control the PID assignment and filtering.

Does the HC1 play any unrepaired transport files obtained from other sources? Like OTA captures from MyHD or other HDTV recorders.

To Ron:

Thanks for the offer for the test patterns. I'm too busy with work at the moment but if you have them available for download, please send me a link via PM and I'll grab them for later.

-Mark

Has anyone managed to run mpeg2repair using windows emulation under Linxu (wine)? Whenever I've tried, I get a Microsoft Visual C++ error, " This application has requested the Runtime to terminate it n an unusual way..."

New version released today. See first post for details.

-Mark

Thanks Mark, this tool is really a must have.

Thanks Mark, I will probably send over a paypal donation soon as this tool is a godsend to check my captures before archiving and for checking D-VHS to PC transfers :)
it also totally corrects the tiny micro glitches in the HDNet Movies captures that choke the MYHD card, a single flashing black square is better than a entire screen pixelization ;)

I could not do without it, Thanks Again

-Gary

Version 1.0.1.3 is available.

Fixed minor bug causing false timestamp gaps to be reported for TMN on BEV. Thanks HDTVFanAtic for reporting the bug.

I can't seem to get the idle priority feature to work. And when forced into idle priority, it'll revert to normal priority when I use the open file dialog. So I have to load the file, manually set the process to idle priority, then click start. Any ideas?

I can't seem to get the idle priority feature to work. And when forced into idle priority, it'll revert to normal priority when I use the open file dialog. So I have to load the file, manually set the process to idle priority, then click start. Any ideas?

Haven't noticed that before. What program are you using to check priority? Keep in mind that there is a process priority and thread priority. I only set the thread priority (process remains at normal). A thread at idle priority will only use idle time no matter what the process is set to. See the table at:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/scheduling_priorities.asp

I'll add some code to explicitly set the process priority for next version but it will not affect the behavior of the program. Even at idle, this tool still puts a heavy load on your hard-drive but there's not much I can do about that. Blame the crappy file I/O in Windows. :D

Note for all users:

There's an issue introduced in version 12 which causes what appears like a stall before the "Find PID's" scan starts. It only happens when working with files on a slow medium like network shares or optical drives. It shouldn't last more than a minute or so. It's something I'm going to fix in the future.

-Mark

Oh, you're right. :) Process is at normal, but the thread is at idle. I was checking with process explorer. Crap disk i/o I've learned to live with, and I sometimes have to suspend threads to manually dictate 'disk priority'.

Thanks

Oh, you're right. :) Process is at normal, but the thread is at idle. I was checking with process explorer. Crap disk i/o I've learned to live with, and I sometimes have to suspend threads to manually dictate 'disk priority'.

Thanks

Just in case it isn't obvious, you can always pause M2R by hitting the cancel button. It will display a confirmation dialog box. As long as it's on this box, it's paused and should use no CPU time.

I don't know if this was intentional, but it's mighty handy: when a recording has zero glitches, the log file is 1 KB. (rounded up in Windows Explorer) If there are errors, the log is larger than that. That 1 KB includes the one error that MPEG2Repair always finds at the end of recordings.

Mark i have been using your excellent tool, for a good while now. I am in the UK and record .TS and .MPG - SD broadcast streams, from UK Digital Terestrial Television (DTT).

I have asked Dan at vrd to include your code into vrd, which i understand he has spoken to you about. I still think if you would get your code implemented into vrd. It would make you money, and make vrd even better than it is now.

The streams i record are never seen in m2r correct, it takes a few seconds to identify the PIDs. Which i stop the scan, then the PIDs are found somtimes. Well for 50% of the time, they are. Maybe this was what you meant by fixing the Europe bug in the history log. It will be nice when the Europe bug is fully fixed. If i process the same video through vrd first. M2R see the stream right away on lpressing scan. But i'm not wanting to process through vrd right away, i need to find all errors first.

I do not repair with your tool, i use it for scanning to find all problems, in the video stream. I then repair the bad bits with either a repeat showing video, or cut out. If i can cut out the bad part, without spoiling the video.

I hope this europe bug will vanish soon. Because with it i can scan only some single stream .TS files. M2R cannot see my UK muxed .TS streams where there is more than one stream in the file. Neither will it scan these streams for most of the time, only 2% or less are succesfull. Then it will scan only the first stream PID found. The drop stream selector, doesn't see the other streams.

I also have a request which will enhance your program. With the mux streams that have more than one stream in them. I need a way to extract these streams, as yet no tool can do this correctly. For the .TS videos i have. Except for vrd, but vrd wants to modify them. VRD Dan has said there is no way to stop it doing that in vrd, at all. If you could implement this into m2r to extract streams from mux .TS files unmodified, that will be of a great help to me, i'm sure to other m2r users too.

And support for SD .MPG program streams that i record with, just as much as .TS streams.

Thanks Robbi :)

By unmodified, by extracting only part of the stream, you are modifying the stream.

If you are speaking of not correcting the errors, then H2M or nullpacket stripper can easily accomplish this.

On another note, M2R does not recognize DTS streams and thus eliminates them. It would be nice to make sure those are not discarded by mistake.

By unmodified, by extracting only part of the stream, you are modifying the stream.
I meant a one complete channel stream, from say a four channel mux .TS stream. But rather would like to analyze all the streams First without extracting, all within M2R.

If you are speaking of not correcting the errors, then H2M or nullpacket stripper can easily accomplish this.
Yes but i really do need to analyze all the streams First, for all possible errors. Which is why i use M2R, there no other tool it seems, that compares to M2R. NullPacket Stripper i have just downloaded, i will try it, even thouh it is It is java. I dislike sun java on any of my media pc's. Will look at a network sollution to a non media pc, to try this one.

On another note, M2R does not recognize DTS streams and thus eliminates them. It would be nice to make sure those are not discarded by mistake.
I take it you mean Digital Transport Streams not a Dolby Theatre System :D

DTT UK SD Pal at least are seen in M2R for .TS streams, but not often is scan possible for the PIDs. Without first resorting to extract or modify the stream. Beats the whole purpose of analyzing the raw stream first. I have used H2M but this is another extra process, unknown what it adds or takes away. Just like VRD but we know that adds and takes away, which is of no use.

.

All these other tools that are not M2R are of no use for analyzing the captured streams. They are just giving me a hopefully temporary workaround, to use the streams in M2R. Hopefully M2R will be able soon to to all the SD .TS streams i load, and the sub streams of multi mux .TS streams. At least then i can know what errors, if any exist in the video before editing. Yes if M2R could also extract these streams unmodified, it would be a cool feature to have. One that you possibly realise is missing also.

I prefer the video as intended, which is the whole point. For me using M2R for finding and identifying, all irregularities in catured .TS and .MPEG-2 videos i record.

The streams i record are never seen in m2r correct, it takes a few seconds to identify the PIDs. Which i stop the scan, then the PIDs are found somtimes. Well for 50% of the time, they are. Maybe this was what you meant by fixing the Europe bug in the history log. It will be nice when the Europe bug is fully fixed. If i process the same video through vrd first. M2R see the stream right away on lpressing scan. But i'm not wanting to process through vrd right away, i need to find all errors first.


Please send me some short samples of the files you're having trouble with. You can post them on yousendit.com and email me the link at the support address. I'll see what I can do to improve compatibility.

Same goes for the DTS audio. I've never seen anyone broadcast HDTV with DTS sound so I would need to check that out.

-Mark

Please send me some short samples of the files you're having trouble with. You can post them on yousendit-com and email me the link at the support address. I'll see what I can do to improve compatibility.

Same goes for the DTS audio. I've never seen anyone broadcast HDTV with DTS sound so I would need to check that out.

-MarkThank you Mark I will upload files for you. I have pm some details to you. I will send email to the support address, after i upload some files.

Robbi

Thank you Mark I will upload files for you. I have pm some details to you. I will send email to the support address, after i upload some files.

Robbi

The link you sent me via PM contains 2 files. One is an .mpeg file which is a program stream and will not be supported. The other one is a transport stream but it contains H.264 video which will also not be supported because my tool is intended only for MPEG2. If you find any valid MPEG2 transport streams that my tool will not handle, please let me know. Thanks.

Ok mark i will pm you another link soon, that may have what you need.

I have had a long chat with a friend recently, he showed me what i was doing wrong with M2R.


1. It turned out to be the dvb software i was recording with, was at fault. It was making incompatable M2R streams. I installed some more softwares, all using bda drivers. Recordings now are seen as they should be. But sometimes they don't see correctly.

2. What i didn't realise with M2R, was the program drop list. Is direct numbers used from the channel SIDs. Now i know this fact, i can select the correct program SID then click to Find PIDs. It then it quickly fills up the blue progress bar.

With these new softwares and information on using M2R i now have no problem. Except for one simple need, that is for splitting the mux'd stream recordings. Would this be possible if wriiten in M2R or another tool. Would it corrupt the extracted stream at all, or leave it as recorded, the latter is needed.

No uploading of files thankfully, as back on dial-up until new BB is working.

Good to hear you've solved your issue. If M2R ever takes more than a few seconds to find PID's, you should cancel and try a different program number. Sometimes it picks a default program that is missing in the file because of the way it was recorded (missing channels not removed from PMT/PAT tables).

As for your other question... Are you asking if M2R can demultiplex the audio and video streams into separate files? Not at this time. I doubt I will ever add that feature but I might release another tool to do it at some point. Seems like there are very few programs that do this correctly without introducing a/v sync problems. VideoRedo should work for now and maybe ProjectX.

Ron's xport is the tool to use for demultiplexing without a/v sync problems.

Ron's xport is the tool to use for demultiplexing without a/v sync problems.

Ron's xport is a very elegant demultiplexer, but it does not offer the sync features that VideoRedo does. Ron will correct me if I'm wrong, but I think xport will lose sync if there are drops in the recording.

Avoiding that needs a very specific treatment that is also implemented with ProjectX, although ProjectX is far behind VideoRedo is general usability. There are many steams that ProjectX cannot handle.

As for your other question... Are you asking if M2R can demultiplex the audio and video streams into separate files? Not at this time. I doubt I will ever add that feature but I might release another tool to do it at some point. Seems like there are very few programs that do this correctly without introducing a/v sync problems. VideoRedo should work for now and maybe ProjectX.
I was asking for a way to, seperating .ts streams complete, from muxtiplexed multiple recoded streams.

Yes to extract .ts streams.

No to elementary streams.


Recording, of a multiplex for example.

Filename:
09-06-06 21:20:24 Films.ts

A mux stream could contain these for example:
Channel One
Channel Two
Channel Three
Channel Four

I need to seperate each of these, into individual .ts streams from within M2R or another tool you make. Because i trust M2R, so i would trust other tools that you make. But the .ts streams need to be extracted without any modification. I am looking for, a simple to use tool like M2R. Nothing that is bloated or needing, java or MS Net Framework installed.

I need to seperate each of these, into individual .ts streams from within M2R or another tool you make. Because i trust M2R, so i would trust other tools that you make. But the .ts streams need to be extracted without any modification. I am looking for, a simple to use tool like M2R. Nothing that is bloated or needing, java or MS Net Framework installed.

HDTVtoMPEG2 (http://www.eecs.umich.edu/~balazer/HDTVtoMPEG2/) does that perfectly. I use it all the time for that purpose.

I was asking for a way to, seperating .ts streams complete, from muxtiplexed multiple recoded streams.

Yes to extract .ts streams.

No to elementary streams.


Recording, of a multiplex for example.

Filename:
09-06-06 21:20:24 Films.ts

A mux stream could contain these for example:
Channel One
Channel Two
Channel Three
Channel Four

I need to seperate each of these, into individual .ts streams from within M2R or another tool you make. Because i trust M2R, so i would trust other tools that you make. But the .ts streams need to be extracted without any modification. I am looking for, a simple to use tool like M2R. Nothing that is bloated or needing, java or MS Net Framework installed.

M2R already does this if you use the repair feature. The repaired output file will always contain only a single program that you selected. You can see the PID values of the program in the status area. To extract multiple programs, you would need to run your file through the program multiple times. This would also be necessary if you want to test each of those programs for errors. My tool can't do any operations on multiple programs at the same time.

By default, if there are additional programs present, my tool will replace them with NULL packets in the output file. So the output file will be about as large as the original (this is used to preserve original mux bitrate). If you change the .ini file setting "StripNullPackets=1", you will then get a smaller file containing only the data from your selected program.

robena is right about the A/V sync issue. That's what I meant when I said very few tools do this correctly. If your file has any timestamp gaps, you will not get a proper demux with anything but VideoRedo or ProjectX (assuming it works with your file). A lot of the code needed for proper demux is already in M2R, I just need some time to get it all working and tested on a variety of material.

Thanks for the info Mark, i use M2R at the moment only to analyze the streams, not for repair. I have tried repair previously, but disliked the block blocks it placed on the video. Times i may see an error is likely to be few frames. M2R locates any errors, which i then replace using cllips, from a repeat showing. This way i get nice video, as shown.

Mark is there any other settings that i should add to the ini file. That will let me pass a multiplexed file through M2R fix. But i don't need any fix, just to demux individual streams one by one. I intend if it is possible to disable, all fixing commands in the ini file.

HDTVtoMPEG2 (http://www.eecs.umich.edu/~balazer/HDTVtoMPEG2/) does that perfectly. I use it all the time for that purpose.
It crashes all to often for me, when loading a file. Crashes on the ones i have to manualy select, from the program number drop list in M2R. Not really had a good chance to play with it yet, because of the crashing.

The colour controls, does it affect the output file at all.?

It crashes all to often for me, when loading a file....

The colour controls, does it affect the output file at all.?Send Cris Moore (H2M author) a clip from a file that causes crashing. In my experience, he fixes H2M so that it no longer crashes on that type of error.

No, it does not affect the output. The video controls are for the monitor window only, so you can see better what you're doing while editing.

Mark is there any other settings that i should add to the ini file. That will let me pass a multiplexed file through M2R fix. But i don't need any fix, just to demux individual streams one by one. I intend if it is possible to disable, all fixing commands in the ini file.

If you set "FixMacroblockErrors=0" it will not replace bad pixels with black blocks. Depending on your player, it might work better or worse by leaving the errors in the file unrepaired. If you're going to replace the bad frames from another recording anyway, then it should not matter if it's repaired or not.

Send Cris Moore (H2M author) a clip from a file that causes crashing. In my experience, he fixes H2M so that it no longer crashes on that type of error.

No, it does not affect the output. The video controls are for the monitor window only, so you can see better what you're doing while editing.
This crashing happens on a lot of recordings. Sending clips could be a headache, as am on dial-up until a new BB starts.

You may be in luck. Cris has just issued an updated H2M with at least one more crash source fixed. Go get it from the H2M thread and see....

If you set "FixMacroblockErrors=0" it will not replace bad pixels with black blocks. Depending on your player, it might work better or worse by leaving the errors in the file unrepaired.
Thanks Mark, i had guessed that one.;)
Just making sure, there wasn't a less obvious setting, to change.

If you're going to replace the bad frames from another recording anyway, then it should not matter if it's repaired or not.
Main thing i will be able to split mux'd stream recordings. Then knowing what errors had been fixed or not. By using the .log files of M2R scans, to compare mux'd vrs demux'd .ts streams.

You may be in luck. Cris has just issued an updated H2M with at least one more crash source fixed. Go get it from the H2M thread and see....
Thanks i'll go and check that right now.

Ah well it didn't work, ive tested it now with a few bda softwares. It gets stuck on the muxd streams that get recorded. Never mind i loaded in again ProjectX to try once more. Can someone tell me if it is possible to dissable totaly file fixing with this tool. Everything is turned of (unticked) but it keeps trying to fix sound video alignment and more.

Mark just a thought for unattended processing. Have you ever though of adding a batch process to M2R. One that could input many files, let the user input manual programe values. Or for muxd streams serveral values, then abilty to save with new file names and drive/folder as specified by the user. The batch to ouput fixed and the .log file, fixed only, or .log file only.

Mark i've uploaded another file, for you to have a look at. The download url details, i will send to you shortly.

Any chance that this program will ever support PVA files as well?

Chris have just got the update v1.0.1.4 after beta stopped working. Can't wait to try it after this evening recording schedule ends.

Will be trying the new feature:
"ForceVideoPID","ForceAudioPID" to ini file. Used for cases where automatic detection fails.

One channel, a new channel, the broadcaster must be still, sorting out the gremlins. This new feature might help with the many recordings, i have gotten from the new channel so far. Which M2R v1.0.1.3 had problems with, will try the new feature later. If works it will save me many of hours by not having to run it through vrd with each file, before M2R can work its magic.

Chris i cannot work out how "ForceVideoPID","ForceAudioPID" works. I have tried setting hex, dec and programme values with or without the ; at the end in the .ini file. So far it doesn't force M2R to see the files, though ts reader sees them correctly. As does other applications see the pids when video is loaded, help appreciated.

Chris i cannot work out how "ForceVideoPID","ForceAudioPID" works. I have tried setting hex, dec and programme values with or without the ; at the end in the .ini file. So far it doesn't force M2R to see the files, though ts reader sees them correctly. As does other applications see the pids when video is loaded, help appreciated.

I think you're getting me confused with Cris, the HDTV2MPEG2 author... :)

I tried the TEST.001, TEST.002, etc. files that someone sent me (I think it was you) that contain no PAT/PMT tables. Those files contained 3 programs. One was on video/audio PID 0x258/0x259 and the other was on 0x26c/0x26d and 0x262/0x263. So I set the ini values like this:

ForceVideoPID=0x258;
ForceAudioPID=0x259;

You then restart the program (ini values are only checked when it starts) and it should open the file after warning you about the missing PMT tables. Just ignore the warning and you should be able to scan or repair the file. You would have to do this again with 0x26c/0x26d and 0x262/0x263 to handle the other programs.

-Mark

Chris?? i agree where did that come from. Could be that i was reading the H2M forum the same time as writing here. :)

So far with multi stream files M2R crashes, send to MS type crash. The crash report tells me to increase the PacketHistorySize, now a big increased PacketSize with playing around with it. Will get dr. watson to output an error code dump, that i will send to you.

What also i have tried is a single stream .ts file that i have entered the correct pids in hex and dec. I have many of these videos all films from a digital film channel. So far i have entered them like this:

ForceVideoPID=0x02BD;
ForceAudioPID=0X02BE;

ForceVideoPID=0x701;
ForceAudioPID=0X702;

The actual program value is 27136

Neither if the above have worked. TS Reader shows these values when video.ts is loaded into it.

0x02BD - Mbps
0X02BE - Mbps
0X0000 - Kbps

The three above values has the Kbps and Mbps values changing in realtime, no other values are shown. Other softwares load the videos without problem. They are from a digital film channel, i have so far recorded many films, little hd space left now. Have not yet been able to edit them yet, as not been able to scan them with M2R for errors as yet. Would like to get these edited, before edit the multi stream .ts files i have. Reading your above post it seems i'm doing it correctly, but just not getting there.


Update:

Mark the Dr.Watson crash dump file for the multistream forcing pids. This log file i have now emailed to you.


Also i have noticed at the end of the log file is a mess, Mark how do i get the Info: to appear again before each report end logging.

Such as:

Info: 0 Errors found in video
Info: i like this info before these
Info: just cannot find the option in the .ini file
Info: to get them to appear in the log again.
Info: No idea why they went missing with the new version of M2R.

Also i have noticed at the end of the log file is a mess, Mark how do i get the Info: to appear again before each report end logging.

Such as:

Info: 0 Errors found in video
Info: i like this info before these
Info: just cannot find the option in the .ini file
Info: to get them to appear in the log again.
Info: No idea why they went missing with the new version of M2R.

You will only get that summary information when it reaches the end of the file (or is canceled) without crashing. A crash aborts the process so there is no summary. I have also changed the format slightly from the last version to include some additional information.

Let's take your crash issue offline. I will email you with additional steps to try.

-Mark

You will only get that summary information when it reaches the end of the file (or is canceled) without crashing. A crash aborts the process so there is no summary. I have also changed the format slightly from the last version to include some additional information.
Appreciate the additional details in the log report, would welcome to see the formatting clean again. With Info: added with the extra new details. :)


Let's take your crash issue offline. I will email you with additional steps to try.
-Mark
Thanks.

I am trying to troubleshoot a problem - and determine if this is real error MPEG2REPAIR is reporting or actually in the E* Stream.

Can I get any MPEG2REPAIR users that sub to SHO-HD to cap Weeds on Sunday night at 9pm or 9:30pm Eastern from SHO-HD? NOTE: This is last showing.

Even the first 2 minutes would be great. Run it through MPEG2REPAIR for the log and see if you get a error/time gap at 1:25 in from the beginning of the ratings screen?

I am trying to determine if this is a problem with E*, a problem with SHO-HD, a false positive with MPEG2REPAIR or what exactly is going on.

As it has appeared in all 7 previous airings of the Weeds episode this week at the exact same time, its a unique opportunity where we know where it will happen to try and troubleshoot it.

Thank you for any assistance.

I am trying to troubleshoot a problem - and determine if this is real error MPEG2REPAIR is reporting or actually in the E* Stream.

Can I get any MPEG2REPAIR users that sub to SHO-HD to cap Weeds on Sunday night at 9pm or 9:30pm Eastern from SHO-HD? NOTE: This is last showing.

Even the first 2 minutes would be great. Run it through MPEG2REPAIR for the log and see if you get a error/time gap at 1:25 in from the beginning of the ratings screen?

I am trying to determine if this is a problem with E*, a problem with SHO-HD, a false positive with MPEG2REPAIR or what exactly is going on.

As it has appeared in all 7 previous airings of the Weeds episode this week at the exact same time, its a unique opportunity where we know where it will happen to try and troubleshoot it.

Thank you for any assistance.

Why do you need other users help for this? Just use your own eyes/ears. If you don't see a problem in the recording or the live feed, then it's obviously a bug in my tool. I'll ask one of my friends who gets SHO-HD from Dish to capture it for me. If it's a bug in my tool, hopefully I can reproduce it here.

-Mark

Here's the log from a 169time setup for the full hour starting about 9PM (ET):

Sequence Frame 2865(545-B) / Time 0:01:50 :
AudioWarning: Timestamp gap of 1.017756 sec. ending at file offset 171801380

Sequence Frame 2874(7-B) / Time 0:01:57 :
AudioWarning: Timestamp gap of 0.976689 sec. ending at file offset 172770198

Sequence Frame 2895(27-B) / Time 0:01:58 :
VideoWarning: TemporalRef gap of 477. Timestamp gap of 5.805800 sec. ending at file offset 171803471

Sequence Frame 2941(73-B) / Time 0:02:00 :
VideoWarning: Timestamp gap of 0.016678 sec. ending at file offset 172154378

Sequence Frame 47104(205-B) / Time 0:31:54 :
AudioWarning: Timestamp gap of 0.016667 sec. ending at file offset 2980563108

Sequence Frame 47113(7-B) / Time 0:31:58 :
AudioWarning: Timestamp gap of 0.975322 sec. ending at file offset 2981534824

Sequence Frame 47134(27-B) / Time 0:31:59 :
VideoWarning: TemporalRef gap of 817. Timestamp gap of 3.269933 sec. ending at file offset 2980565239

Sequence Frame 47164(57-B) / Time 0:32:00 :
VideoWarning: Timestamp gap of 0.016678 sec. ending at file offset 2980869082

Sequence Frame 55826(530-P) / Time 0:38:01 :
VideoError: Invalid motion vector code. MBA=3501(336,464)
VideoError: Failed to decode macroblock at MBA=3501(336,464)
FileInfo: Last video errors span 1205 bytes at file offset 3569424550

Sequence Frame 89463(374-P) / Time 1:00:41 :
Info: End of MPEG2 sequence

Sequence Summary:

File Size Processed: 5.31 GB, Play Time: 01h:00m:39s
1920 x 1080, 29.97 fps (24.58 fps Telecine), 18.00 Mbps (11.80 Mbps Average).
Average Video Quality: 58.60 KB/Frame, 0.23 Bits/Pixel.
AC3 Audio: 3/2 Channels (L, C, R, SL, SR) + LFE, 48.0 kHz, 384 kbps.
Dialog Normalization: -27.0 dB, Center Mix Level: -3.0 dB, Surround Mix Level: -3.0 dB
1 of 89463 video frames found with errors.
0 of 113724 audio frames found with errors.
1205 corrupted video bytes in file.
9.109089 seconds of video timestamp gaps.
2.986433 seconds of audio timestamp gaps.

End of Log


Same old story for Dish. One error and missing about 10 seconds of programming. Maybe you can ask them for a refund. :)

Their "HD" service is very unreliable and only continues to get worse as they switch everything over to HD-Lite. Just be glad this channel is still in HD (for now). I gave up on them and switched to cable. I don't need PC recording capability when the picture quality sucks and it's full of errors.

-Mark

I just posted my resilts in the R5000 thread, recorded the 9:00 PM using a cable box, no errors were found using mpeg2repair.

Sequence Frame 38691(0-I) / Time 0:26:45 :
Info: End of MPEG2 sequence

Sequence Summary:

File Size Processed: 2.37 GB, Play Time: 00h:26m:45s
1920 x 1080, 29.97 fps (24.09 fps Telecine), 80.00 Mbps (11.89 Mbps Average).
Average Video Quality: 60.22 KB/Frame, 0.24 Bits/Pixel.
AC3 Audio: 3/2 Channels (L, C, R, SL, SR) + LFE, 48.0 kHz, 384 kbps.
Dialog Normalization: -27.0 dB, Center Mix Level: -3.0 dB, Surround Mix Level: -3.0 dB
0 of 38691 video frames found with errors.
0 of 50181 audio frames found with errors.
0 corrupted video bytes in file.
0.000000 seconds of video timestamp gaps.
0.000000 seconds of audio timestamp gaps.

End of Log

Its interesting that your log shows the bitrate header at 18 mbps and mine from cable shows 80 mbps. When I used a 169Time box with Showtime from C-Band I always got the 80 mbps headers.

Mike T

Why do you need other users help for this? Just use your own eyes/ears. If you don't see a problem in the recording or the live feed, then it's obviously a bug in my tool. I'll ask one of my friends who gets SHO-HD from Dish to capture it for me. If it's a bug in my tool, hopefully I can reproduce it here.

-Mark

I used my eyes and ears :) I was just trying to figure out the source of the issue so hopefully we could get it fixed - wherever the issue was. That means troubleshooting and the more data the better - especially given the repetitive nature of this one.

The interesting thing was I did actually see the glitch this time - its in the opening titles....

I also capped it via cable on a HD-DVR and it played right through with no glitch.

It's clearly a E* issue - interesting its happening at the same point EVERY TIME with their SHO feed. Most glitches they have on E* are not repeatable in subsequent airings - which makes this one even stranger.

The thing EVEN STRANGER is that since its in the opening credits, it repeated EVERY WEEK on Weeds - yet for some reason its only this episode that the E* muxers choke on it.

hi!

First, thanks for this exellent tool.. I've used it for well over a year now,
as an integral part of my recording setup.

I just have a small problem..
Out of the blue, one of my computers cannot execute the program
without getting a "this beta version has expired." error.

It's the latest version, and it _does_ work on my other computer.
I don't really know what to do, help would be greatly appriciated =)

Greets,
/Per

If it says it expired, it isnt the latest version. Re-download from link in post #1. Only expired versions will give you that error. Clearly you updated it on one but not the other.

If it says it expired, it isnt the latest version. Re-download from link in post #1. Only expired versions will give you that error. Clearly you updated it on one but not the other.

My ver: 1.0.1.4 (Aug 14)

I guess it can be blamed on my computer alone; something is clearly not alright.
I digged out the registry key that defines "expired" or not, so I can start
and use it now.
But the inherit function to decide if it's expired or not is obviously
going quite wrong on my machine.

I'll probably find my solution within my own system, obviously,
but it'd be nice not to have to reinstall my machine just because
I cant find what caused this.

/Per

My ver: 1.0.1.4 (Aug 14)

I guess it can be blamed on my computer alone; something is clearly not alright.
I digged out the registry key that defines "expired" or not, so I can start
and use it now.
But the inherit function to decide if it's expired or not is obviously
going quite wrong on my machine.

I'll probably find my solution within my own system, obviously,
but it'd be nice not to have to reinstall my machine just because
I cant find what caused this.

/Per

The system date on your computer is checked by the program when it starts. Has nothing to do with a registry setting.

So, if you mpeg2repair.exe file is old, it will say its expired. He usually has a 3-6 month window on the program to make people use the updated versions.

If you will check the .exe file on the computer it does not work on, there are only 2 options - 1) you have the older .exe on that machine or 2) The Date on your system clock is incorrect.

Other than that, you are pretty much out of choices.

does anyone know what the plan is for timecode correction, or perhaps even the addition of additional streams (e.g., audio streams) into the MPEG2 repair process?

Hi Wizziwig - Any reason why the link is not working? We get Adelphia.net's users page instead of your page

Thanks.

Last I heard from him a month ago, he had lost interest and motivation in the program as E* had gone to HDLITE on HDNET :(

ouch,

I was hoping for an H264 version....

Hopefully he releases a version without a "timebomb" before calling it quits.

Anyone else having problems with the download page? Seems to be working for me now but it's probably just a matter of time before it goes down as my ISP moves everything from former Adelphia to new TWC servers. I'll update the links when that happens.

As for the "timebomb", I think I made it clear that this is "Beta" software. I know some people don't care if their buggy code lives on forever on the net, but I prefer to do things differently. Forcing everyone to run the latest version also simplifies my support and bug tracking job. This is FREEWARE! People are free to use other tools if this bothers them.

I will probably release a final version without expiration date sometime soon, as I'm not planning to continue this project much longer. As HDTVFanAtic pointed out, I just don't have much interest in this tool anymore. Why bother recording crappy overcompressed programming from OTA/Cable/Satellite now that HD titles are available for purchase?

-Mark

Why bother recording crappy overcompressed programming from OTA/Cable/Satellite now that HD titles are available for purchase?

-Mark

Mark, your tool has been and still is invaluable to assess the quality of series cap, which won't be available for purchase before a long time.

You deserve all the possible thanks for it. I certainly understand that movies being your main interest makes you stop maintaining it, but it will be still a great help for series.

So, whenever you're ready for it, a non time-bombed version will be very much appreciated.

I also hope that you release the source code for the software. There are very few pieces of software that I use as often as I do MPEG2REPAIR.

if it's a question of financial justification, I would be very happy to paypal you a bit of cash to reflect my appreciation on this wonderful piece of software!