Various questions about audio handling (AC3, E-AC3) and side car files

zekepliskin

Member
Here's a scenario I've encountered recently when testing what the HDR Fox T2 will and will not play correctly.

I have a TV show episode originally in a MKV container. It has 1080p level 4 H264 video and 640k E-AC3 audio.

I can use ffmpeg to remux it to a TS or M2TS file and it'll play correctly on the HDR Fox T2, no issues (I forgot DD+ is supported). The webif [sidecar] fails to generate the correct NTS file as it moans about lack of H264 SEI units however so I can't add episode info.

TSmuxerGUI won't remux files with E-AC3 as it can't handle them. AV2HDR-T2 won't either, I assume because DD+ is an AAC derivative.

Is there any way to get H.264/E-AC3 files to remux to a TS with sidecar files? I mean, I can get ffmpeg to transcode E-AC3 to AC3, then remux to TS with TSmuxerGUI, then remux again with AV2HDR-T2 but it's a bit convoluted. There must be a flag I can use to make ffmpeg build a M2TS that [sidecar] will happily build compliant HMT/NTS files for.

---

Another one.

If I use TSmuxerGUI to remux a file with H264 video and AAC audio then use webif [sidecar] to generate the HMT/NTS this works fine, plays with no issues.

However, if I use TSmuxerGUI to remux a file with H264 video and AC3 audio, the bare file itself will play on the HDR Fox T2 but as soon as [sidecar] generates the HMT/NTS files it plays without audio.

Yet the same file if remuxed with AV2HDR-T2 will play both audio/video correctly with generated sidecar files present. I traced the fault to the [sidecar] HMT files because if I interchange the one made by AV2HDR-T2 on the same video file the audio works again. All for the want of a 2KB file eh?

--

Any tips appreciated. I was trying to find the right command line options with ffmpeg into the wee small hours of the morning lol...
 
I traced the fault to the [sidecar] HMT files because if I interchange the one made by AV2HDR-T2 on the same video file the audio works again. All for the want of a 2KB file eh?
It should be easy enough to work out the difference between the .hmt files and then you can patch the sidecar generated one in future. Do you want to zip and post or try it yourself with hexdump and diff?
I was trying to find the right command line options with ffmpeg into the wee small hours of the morning lol...
BTDT. ffmpeg can be a desperately frustrating beast.
 
It should be easy enough to work out the difference between the .hmt files and then you can patch the sidecar generated one in future. Do you want to zip and post or try it yourself with hexdump and diff?

I appreciate the offer but it's all good now, I just did the "remux with TSmuxerGUI, remux again with AV2HDR-T2 and add info for sidecar files, FTP to HDR Fox T2" method and everything plays okay.

BTDT. ffmpeg can be a desperately frustrating beast.

Understatement! Very useful being able to move some of my favourite shows onto the HDR Fox T2 though, as I'm running out of space on my HTPC shared drives. Got loads of smaller harddrives hanging around but with a total 6TB on both mine and my partners HDR Fox T2 (which I've remuxed some BBC iPlayer shows she likes onto there as ripped via get_iplayer) it makes sense to get them working. Amazing they can even do this - great design on part of the Humax engineers firstly and the dedicated hobbyist programmers looking after the Custom Firmware for us lucky people. As my parents also own a HDR-2000T it means I've been able to mux files for that knowing that if my box plays it theirs will too (the UI is nearly identical). In fact I've done that for This Is Us recently, see if they like it... anyway I'm rambling off topic so I will digress.

In order for the HDR-FOX to see your H.264 (AAV) + AAC .ts (M2TS) file as a legitimate self-made recording and therefore play nicely.

Ah I see what you mean, thanks for the clarification. Well it can play H.264/AC3 with sidecars as long as AV2HDR-T2 muxes it anyway. It's still impressive that it can also handle H.264/E-AC3 DD+ content as well, just not with sidecar files.

The solution for testing was simple, but I was so deep reading the manpages for ffmpeg in the wee small hours I missed it :- take the original H.264/E-AC3 file and remux it with TSmuxerGUI. This produces a file with correct SPS/PPS entries for the video and then the [sidecar] plugin doesn't complain it can't complete the NTS file generation. Use ffmpeg to remux the VIDEO from the new TS file and the AUDIO from the original MKV file and test.

Well, the bare M2TS file renamed to a TS played, again. Plugin [sidecar] completed with no visible errors on the webif... and the resulting file was apparently 1591min in length and played video but no audio. I call that a conclusive enough test and say that the best result you can get with E-AC3 aka Dolby Digital Plus files is playback in an ffmpeg M2TS container remux and no sidecar files. Ah well. If I ever get lazy at least it's a one remux from original MKV and FTP across to a playable basic file. No bookmarks though! :-D

The real question I have now is, if the DVB-T2 standard supports Dolby Digital Plus and the Humax can bitstream it, why are no HD Freeview channels using it? Seems like a better solution than relying on the by now very old MP2 and AC3 standards.
 
Last edited:
if the DVB-T2 standard supports Dolby Digital Plus and the Humax can bitstream it, why are no HD Freeview channels using it?
If... Does it? More likely the SoC happens to have the capability built-in than the Humax engineers deliberately putting it there.
 
If... Does it? More likely the SoC happens to have the capability built-in than the Humax engineers deliberately putting it there.
D-Book 7 Part A does specify that broadcasters can use "E-AC-3" (TS 102 366) or "MPEG-4 High Efficiency AAC" (ISO/IEC 14496-3 up to HE-ACC Level 4) when the video is not SD MPEG2. Freeview HD receivers should be able to cope with both of these.
 
D-Book 7 Part A does specify that broadcasters can use "E-AC-3" (TS 102 366) or "MPEG-4 High Efficiency AAC" (ISO/IEC 14496-3 up to HE-ACC Level 4) when the video is not SD MPEG2. Freeview HD receivers should be able to cope with both of these.

Exactly, I knew I'd read that somewhere! And the HDR Fox T2 does cope perfectly with reproducing DD+/E-AC3 streams, as does my Sony BRAVIA TV which can also resample E-AC3 back to AC3 when outputting via SPDIF.

American TV seems to be using E-AC3 as a regular thing these days - from what I can tell a lot of the channels which have 1080i streams use E-AC3 for any broadcasts which have surround sound. Not sure why we don't here in the UK; I reckon interoperability reasons of some kind.
 
Not sure why we don't here in the UK; I reckon interoperability reasons of some kind.

Or maybe itv is and always been shite in respect of keeping to original ratios and original surround sound. Ch4 and bbc much better. Recently I happened onto surround sound Simpsons.
 
Or maybe itv is and always been shite in respect of keeping to original ratios and original surround sound. Ch4 and bbc much better. Recently I happened onto surround sound Simpsons.

Yep, ITV cut corners in terms of video quality, audio quality... which mirrors their content which on the whole is a load of shite anyway. Unless there's sport I basically just forget that network exists lol.

BBC and Channel 4 have HD offerings with correct (non-cropped) aspect ratios on films and usually 5.1 surround too. Pretty impressive.
 
It should be easy enough to work out the difference between the .hmt files and then you can patch the sidecar generated one in future. Do you want to zip and post or try it yourself with hexdump and diff?

Found it! Got tired of doing things the long way round and remuxing files multiple times to achieve a result.

Code:
In the HMT File it is Offset 488 which defines audio type.

  • When using AV2HDR-T2 to remux a H.264/AC3 640k bitrate video for use with the HDR Fox T2, this HMT file block is correctly set to 00.
  • When using sidecar to recreate the HMT for the same file it is incorrectly set to 01 - I believe this is correct only if the audio is AAC. Swapping an AAC equipped TS file to 00 similarly breaks the audio so this seems to check out.
There are a few other things, for example that 84 seems to be set for some Dolby Digital 2.0 originally recorded from broadcast files, which incidentally still allows the AC3 5.1 640k equipped file to play correctly if set in their HMTs. I have a feeling that this byte may actually allow a correctly muxed .TS file with H.264 video and E-AC3 (aka Dolby Digital Plus) to play correctly with sidecar files and i-plate info. Seems like it would be a case of running the byte from 00 to FF to see if there's a match, which I'm probably curious enough to do at some point, allowing successful muxes with H.264 video to have either AC3, AAC or E-AC3 audio and their sidecar files built.

I have no idea who maintains the sidecar package but if someone knows, it may be worth passing this information along to them so it can be updated, allowing AAC and AC3 audio to work correctly on sidecar built TS support files. This would be a lot more convenient than hex editing HMT files generated by the package...
 
Found it! Got tired of doing things the long way round and remuxing files multiple times to achieve a result.

Code:
In the HMT File it is Offset 488 which defines audio type.
...
and also, earlier,
I have recently copied ... several VOB files with MPEG2 video and AC3 audio. I used TSMuxer GUI to join the VOB files and remux them to a single m2ts file per recording. I then created sidecar files using the Sidecar package on the HDR-FOX T2, or alternatively used AV2-HDR T2 on a Windows PC. In both cases, the recordings play on the HDR-FOX T2 without sound. I found that changing the value at offset 0x0488 in the hmt file to zero enables audio playback, but it is a bit of a bodge.
...
Offset 488 (neither 488 nor 0x488) doesn't define audio type in my .hmt files nor in the Wiki. Rather it's 0x4A0.

What am I missing?

Should anyone have a recording with the wrong audio type in its .hmt, a command like hmt +patch8:0x4A0:$type $recording would fix it.
 
Offset 488 (neither 488 nor 0x488) doesn't define audio type in my .hmt files nor in the Wiki. Rather it's 0x4A0.

What am I missing?

Should anyone have a recording with the wrong audio type in its .hmt, a command like hmt +patch8:0x4A0:$type $recording would fix it.

So then the simple conclusion to why this works is HMT files are not fully understood then, I suppose? Because I can mux the file with AV2HDR-T2 and that 0x488 is set to 00 for AC3 files whereas if the same file is muxed with TSmuxerGUI and the sidecars made on the webif it's set to 01 which causes no audio. There must be a technical reason for this. I tried changing the 0x488 offset from everything to 00 to about A0 before I gave up but couldn't find a change that would make TS with attendant HMT/NTS files with E-AC3 play, guess it just won't work. Shame really, would save a lot of time transcoding E-AC3 to AC3 and then remuxing rather than a straight up TS remux and build sidecars on the box.

EDIT: Oh while I'm here is there an easy way to batch a directory using terminal into the HDR Fox T2? I.e. point sidecar at a whole dir and have it automatically draw the NTS/HMT files up if missing for *.ts files. Another timesaver I could really use, then come back and add the i-plate stuff later.
 
Last edited:
Last edited:
Found it! Got tired of doing things the long way round and remuxing files multiple times to achieve a result.

Code:
In the HMT File it is Offset 488 which defines audio type.

...

and also, earlier,

Offset 488 (neither 488 nor 0x488) doesn't define audio type in my .hmt files nor in the Wiki. Rather it's 0x4A0.

What am I missing?

Should anyone have a recording with the wrong audio type in its .hmt, a command like hmt +patch8:0x4A0:$type $recording would fix it.
Don't know where you got your original info regarding offset 0x488. It has always been, and still is, defined as ProgID.
What you are missing is a bit of simple research in the sidecar release thread.
Suggest you read this post in particular, from that thread, then try the sidecar -x switch, put in place especially for the circumstance you describe regarding non-native import audio streams.
And if you are going to try patching values in attempt to get E-AC3 to play, patch the correct one at 0x4A0, not 0x488. (known values are MPEG=0x01 AC3=0x03 AAC=0x07) and report any success here.
 
Last edited:
Don't know where you got your original info regarding offset 0x488. It has always been, and still is, defined as ProgID.

Ah, some info from the man himself. Nice to speak again raydon, been a while.

I believe me and MontysEvilTwin must have "stumbled" on the same cludge of a solution. Why changing ProgID turns broken AC3 audio into working AC3 audio is a mystery to me (currently at least), but whatever it is pointing a hex editor at the HMTs in question and changing that one byte does it.

Suggest you read this post in particular, from that thread, then try the sidecar -x switch, put in place especially for the circumstance you describe regarding non-native import audio streams.
And if you are going to try patching values in attempt to get E-AC3 to play, patch the correct one at 0x4A0, not 0x488. (known values are MPEG=0x01 AC3=0x03 AAC=0x07) and report any success here.

Good advice, thanks. I do love a good technical read to expand my understanding of the HDR Fox T2, a piece of tech I like very much. If I find a solution to getting DD+ working in M2TS files renamed to TS and sidecar'd to create the HMT/NTS files then I'll glad share it. I'd like to know myself because then it's a much simpler process to get a working file with i-Plate details onto the box, it would make it :-

  • Remux source MKV with H.264 video/E-AC3 audio as M2TS directly to My Video series folder using TSmuxerGUI.
  • Rename file to TS and build sidecar files.
  • Add episode info/name as copy/pasted from TVDB
  • Play and enjoy
Incidentally isn't there a way to get TVDB info to link up via a scraper? I know I've seen it in the package list but am stumped as to how to do this.

---

EDIT:

I just checked the 0x4A0 offset for a recent H.264/AC3 equipped episode I uploaded to the box, muxed in TSmuxerGUI as a M2TS and then renamed, which sidecar made the HMT/NTS files for.

0x4A0 offset byte is already 03, which implies it should already be playable with AC3 audio. Surprise surprise though, it is still silent when played. So 0x488 still had to be changed from 01 to 00 in order to "fix" the audio, which it did.

Even with my relative ignorance on the technicialities this leads me to believe that despite the fact 0x488 is the ProgID as according to the wiki sidecar needs to set 0x488 offset byte to 00 by default, not 01. If a HMT file requires either a hex edit or a terminal command after it's been built because the video doesn't play with sound even though it is in a supported audio format, this suggests the package needs an update does it not? At the least maybe an extra checkbox option in the webif along the lines of "Set ProgID 0x488 to 00 in HMT file (only required if no sound on AC3 audio files)", what about that?
 
Last edited:
Didn't you read the post in the link I gave you ? That's exactly what the sidecar -x command line option does. It zeroes the PMT and ProgID's. That's what it's for, so use it from the command line to create sidecar files with an HMT containing a zero ProgID instead of hex-editing your HMT afterwards. 1 is not the default for the created HMT file, it is whatever the ProgID of the source video is. Try sidecar -i to get info on your source video. I think you'll find that the ProgID of your source video is actually 1. I won't be making any changes to the sidecar binary for the reasons I also made very clear in that post. sidecar is for native video only. Changing the webif interface hooks to add a -x option is a possibility, but I won't be doing it. af123 did the original webif hooks. Maybe he will find time if you ask him nicely.
 
Last edited:
Fair points one and all, raydon. And yep every video I've tried with the -x switch enabled which is H.264/AC3 works perfectly. And you know what? Way better using the command line to generate the sidecar files because I can easily batch multiple episodes by chaining things together with &&, and the nice thing is the terminal emulator I'm using then gives you a progress bar on the taskbar so it's easy to tell at a glance when everything has finished. Timesaving/automating stuff like that makes it a lot easier to get non-native stuff on the box. So thank you!
 
... [offset 0x488] has always been, and still is, defined as ProgID.
...
The HMT Wiki table (previously referenced) uses the term "Service ID".

Is "ProgID" a synonym for "Service ID", or a replacement term, or are these two diifferent interpretations of the same field, perhaps depending on some other HMT field value?

Either way, should the HMT Wiki table (previously referenced) be updated at all?
 
Back
Top