As others have pointed out, putting cuts only on keyframes and making sure that you use only a single cut point at the beginning and end of a recording improve the odds considerably.

But not completely. I still have problems with about 25% of recordings dropping audio for good after a cut -- usually not the first pair of cuts but some distance in. In these cases I've tried moving the cuts at the point where the audio drops out and have had no luck. In a couple of cases, I've gotten it to work by removing all cuts completely and putting them all in by hand without relying on the commercial-flagging suggestions, as it were.

Is it possible that the commercial-flagger causes the edit mode to lie about what's a keyframe and what isn't? There seems to be some kind of pathological interaction here.

When I said "relying on the commercial-flagging suggestions" in the previous post, I meant "using them as a guide to get near the proper place and then selecting a nearby keyframe".

My question is this, I guess: If you start editing a recording, and press 'Z' to show the commercial flag locations, put the editor in keyframe-to-keyframe navigation mode, and then
a) press pgdn to get to the next flagged point, and
b) press left and right arrows to get to a keyframe one side or the other of the flag, and
c) press enter to place a cut, and then
c) select "move this cut point to the current location"

... do you really get a cut point on a keyframe?


t.

Simple answer is no you don't.

There is a problem with the cutlist editor and/or mythtranscode in that they don't both use the same frame numbers I'll try to explain what I think is going on.

The problem is they don't agree on which is the first frame. When you see frame number 00:00:00.01 on the OSD in the editor that is not always the actual first frame in the file but in the test I did it was actually the13th frame. So if you, lets say, place a cut point on a key frame at 00:00:00.10 that gets stored in the cut list as frame10 but you are actually seeing frame 00:00:00.23 on the screen . mythtranscode on the other hand always starts counting from the actual first frame. So when it's told to put a cut at frame 10 it does exactly that but you really want it to start at frame 23 in this example. Either the editor should start its frame counting at 1 like mythtranscode or mythtranscode should start its frame counting at the same frame that the editor does (what frame that is is anyones guess).

So basically it doesn't matter how actuate you are at placing the cut points, whether on a key frame or not, they don't end up at the exact frame you put them. In the test I did all the cuts where 13 frame early. If you have ever been really meticulous at placing cut points only for there to be 1/2 a second or so of junk before a cut then this is the cause.

Folks:

I've confirmed to my own satisfaction that Paul's 13-frames-off theory works, at least on a small sample. I had a very stubborn movie recording that was showing the same symptoms I've been encountering a lot: audio disappearing after a commercial cut some distance into the recording. I adjusted the cuts in the recordedmarkup table by simply manipulating the database (+13 frames for all type 0 and 1 cuts except the first one on frame 0) and lo and behold the silly thing worked. I'm trying a few others, but I think we're on to something here.

But there are still puzzling aspects to this. If the audio-dropping-out-after-cuts problem is happening because the cut doesn't fall on a keyframe, and it doesn't fall on a keyframe because the OSD is lying about where the keyframes are by 13 frames, then how come it doesn't fail all the time? Much of the time recordings that have only been trimmed at the beginning and end (as with a commercial-free movie on TCM) are fine. Not always, though. And recordings that fail tend to do so not after the first cut, but a couple of cuts in.

My head hurts. Is there no way to fix this for good? Any minute now I'm going to act like a real luser and start whining about how it worked fine in the old version

Folks:
When working on this problem I've been using commercial-free movies from TCM, because I record a good number of them and because, cuts-wise, they're simple -- trim off the beginning, trim off the end, and you're done. Working with one of these over the last day or so I've come across the following:

1) Some programs simply would not record sound to DVD -- the images would be fine throughout, but there would be no audio.
2) Every program for which this was the case would show a "flash" of picture at the very beginning even though in theory a single cut had been placed on a keyframe at, say, 30s in when I trimmed the beginning of the program. No clue as to how long this "flash" is, but the 13 frames that have shown up as a magic number in this thread before might be a good guess.
3) Deleting all rows in the recordedmarkup database that have anything to do with the program did not help -- in other words, it doesn't seem to make any difference whether commercials have been flagged or not. For some reason mythTV wants to show me the first half-second or so no matter what I tell it I want to cut.

This problem has actually been around for a while -- my .19 version would do the same thing and it used to drive me crazy thinking that somehow I'd munged the cuts at the beginning of the program. Bottom line is that it just does this sometimes, and mytharchive doesn't like it.

t.