Opened 14 years ago

Closed 14 years ago

#2796 closed patch (duplicate)

Silent audio track created using MythArchive

Reported by: anonymous Owned by: paulh
Priority: major Milestone: unknown
Component: mytharchive Version: 0.20
Severity: medium Keywords:
Cc: Ticket locked: no


MythArchive? gives presidence to lower audio PID's, but this is not always the case. In the UK, DVB-T includes a hard-of-hearing audio track (which sometimes is just silence), and MythArchive? is sometimes picking this instead of the correct track. Could we instead use the track which has the highest bitrate? I've attached a diff that will do this. Another idea would be to use bitrate as the first measure, and PID second maybe?

Attachments (1)

diff (7.2 KB) - added by anonymous 14 years ago.

Download all attachments as: .zip

Change History (9)

Changed 14 years ago by anonymous

Attachment: diff added


comment:1 Changed 14 years ago by anonymous

Type: defectpatch

comment:2 Changed 14 years ago by anonymous

Looking into this further, the Audio Description track should be detectable from the stream rather than relying on the bitrate being low. The nebula software seems to support this, if you go to and search for 'Audio description' you will see what I mean.

Unfortunately I am unable to provide any details of what stream headers need to be checked to determine whether each track is an audio description track. Maybe it could be analysed somehow???

comment:3 Changed 14 years ago by anonymous

I've just stumbled across the mpgtx package ( which find information about a stream and can detect the hearing impaired track. Maybe we could call this and parse its output, or incorporate what it does into libavformat?

comment:4 Changed 14 years ago by paulh

Thanks for you effort to fix this, it is much appreciated, but we have to be carefull not to break things for other parts of the world. Using the highest bitrate isn't going to work in all cases and this can happen with any audio streams not just the Audio Described ones.

I think MythArchive? is using the correct method to select the audio tracks. The audio track with the lowest PID should be the main audio track at least that is correct with a virgin DVB-t recording. The problem is actually caused by mythtranscode --mpeg2 which sometimes changes the order of the audio tracks causing the stream IDs to become mixed up.

I've never actually been able to reproduce this myself so if you can provide a small sample file that you know produces this problem that would help to get this fixed. Obviously I need the original file before its been processed by mythtranscode so I can see what's going on when mythtranscode --mpeg processes it. This problem is just one of several problems caused by mythtranscode and mythreplex so John Drescher is currently working on adding an option to use projectX rather than mythtranscode to do the commercial cutting and the demuxing which should hopefully fix many of these problems. It isn't an ideal solution but if it works.....

comment:5 Changed 14 years ago by pdbailey@…

I have seen the mixing up of the audio files on DVB-T here in the UK, and I don't believe that it had been run through transcode.

I'll have a look this afternoon, and see if that did occur. If so, I'll attach a small sample file here

comment:6 Changed 14 years ago by anonymous

I've done a couple of recordings but the PID's seem to be in order like you mentioned. I'll look into all my existing recordings and get back to you (I've only run mythtranscode on four of them)...

PS. Regarding ProjectX, this would be very useful - I've noticed av sync issues with mythtranscode too.

comment:7 Changed 14 years ago by anonymous

I think you're right, looking through my recordings it must be mythtranscode thats mixing up the PID's. Should I re-categorise this ticket under mythtv instead of mytharchive?

comment:8 Changed 14 years ago by paulh

Resolution: duplicate
Status: newclosed

This is really a problem with mythtranscode and is a duplicate of #2468

Note: See TracTickets for help on using tickets.