HDR-Fox T2 recordings to PC - audio messed up

aks100

New Member
I'm sure I've read about this issue, but no matter what searches I try I cannot find any reference to it - be gentle with me if you know another thread, I did try search ;)!

The issue I'm observing, some recordings copied from the Humax are perfectly fine, decrypted HD, or SD, audio and video all good. I cut out ads, save to H264, done. I use various tools depending on the day, but typicall Handbrake for .TS to H264 conversion.

Some files however have audio problems. Typically audio is present, but instead of voices, I hear background music. If I view the file before editing in VLC, video looks fine, audio is wrong. I can then disable the audio (disable track 1), then re-enable track 1, the sound work fine, so the audio tracjk is in fact there and good. I seem to remember an old thread that said it is due to the initial frames of video/audio being corrupted or something?

I tried opening in various editors/splitters (Avidemux crashes, TS_Doctor crashes, LosslessCut no audio, Handbrake no audio in output).

Any help with a flow/tool that will work?
 
The problem you describe is typical of the condition where the broadcaster changes the audio type from 2-channel stereo (eg during the ads that precede the program) to 5.1 during the film or whatever. Most PC-based video converters and many players can't cope with this.

The solution that works for me is to start playback on the HDR, set a bookmark at the instant the main program begins and then use the 'crop' function within the WebIf to remove the section before the bookmark. It takes a few minutes but has worked every time for me - trust this helps.
 
Agreed. The TS format used for broadcasting is designed to accommodate format switching, and TVs/STBs TS codecs specifically watch for format changes and track them. Not so media players.
 
I cropped the ad at the front and yes it seems to now play immediately ok in VLC on the PC. I'll try full editing in a day or two and confirm all ok.
 
Using the crop function (including with detectads) can result in a few seconds of silence when the program resumes after an ad-break presumably due to the audio codec switching.
I have never had the time or inclination to investigate whether it would be possible to fix this within nicesplice.
 
Would it not therefore be possible to detect ads. more accurately in certain cases by clipping the 2.0 stuff and keeping the 5.1 stuff, without needing any other processing?
 
Would it not therefore be possible to detect ads. more accurately in certain cases by clipping the 2.0 stuff and keeping the 5.1 stuff, without needing any other processing?
Interesting idea, but only where there are audio switches to detect. I rarely see problems with quiz shows because presumably they aren't recorded with 5.1.

I have never looked at the detail of the data streams but I assume that the audio stream has periodic key frames that identify the codec but that they don't necessarily correspond with video i-frames.

Nicesplice already aligns cut points with i-frames and could possibly also take codec switches into account as well, but it uses the .nts file to locate i-frarmes so unless codec switches are included in the nts format (I don't think so) it would take a significant rewrite to find them.

The Silence program used to find the ad breaks processes an mp3 file extracted by ffmpeg so if the codec switches are visible it could use them to detect the breaks instead of just silences.

The ideal would be to detect ads directly within the .ts file without needing the overhead of ffmpeg.
 
Back
Top