Convert AC4 Audio to AC3

[hdmkv]

There was an AC4 audio thread in this forum I no longer see. In it, a Windows app was suggested, with command line, to convert a ATSC3.0 capture w/AC4 audio in it to one with AC3. Anyone remember this tool & method? Thanks.
Edit: Solution below...

[hdmkv]

Found the app, but not the command line needed to convert.

[hdmkv]

And, never mind, figured it out. If anyone is interested in archiving non-DRM'd ATSC3.0 recordings, with conversion of AC4 to AC3:

1. Download VideoPlayer app linked above, and install it to your C drive or anywhere that isn't Program Files
2. Save the script here as whatevername.bat, and copy it over to the folder where you installed the above
3. Copy the ATSC3.0 .mpg recording from your HDHR to above folder
4. Run whatevername.bat, and you'll end up with a remuxed file with AC3 audio

Okay, done talkin' to myself .

[DSperber]

There was an AC4 audio thread in this forum I no longer see. In it, a Windows app was suggested, with command line, to convert a ATSC3.0 capture w/AC4 audio in it to one with AC3. Anyone remember this tool & method? Thanks.

That AC4 audio thread was from 2+ years ago. I learned about this idea and had communicated with the author of that VideoPlayer project you point to above in this thread in your "solution", along with its derivative which was a version of Kodi capable of producing sound from ATSC 3.0 programs with AC4 audio.

The goal of my own effort, like yours, was to support AC4 audio through the use of a command that made use of the modified version of FFMPEG.EXE (contained in those GitHub projects) which actually performed the audio decoding (using its own "free" code modified from standard FFMPEG.EXE), rather than paying for the official not-inexpensive paid/licensed Dolby commercial codec built into TVs, phones, new NextGen ATSC 3.0 devices, and other new hardware.

At the time when I was playing with this and trying to use TS recordings made by NextPVR from my Flex-4K tuner. NextPVR itself did not handle AC4 audio. So I did the same type of experimenting you did, trying to convert input non-encrypted non-DRM ATSC 3.0 recording files out of NextPVR into MP4 output that contained transcoded AC4->AC3 audio, and that I could then play through my A/V system.

Here is an example of the command which I believe you were looking for (note that I used fully-qualified paths in my command, for flexibility in having input and output files wherever I wanted them to reside):

"c:\program files (x86)\VideoPlayer AC-4\ffmpeg.exe" -i "F:\WinTV\NFL Football\NFL Football_20211216_17002030.ts" -c:a eac3 -map 0:0 -map 0:2 -af "channelmap=0|1|4|5|2|3:5.1(side)" -vcodec copy "M:\Transcode\NFL Football_20211216_17002030.mp4"


IMPORTANT NOTES:
--------------------------

(1) I do not know if the version of FFMPEG.EXE that you will find in that VideoPlayer project on GitHub (which still shows that it is 3 years old), so I'm not sure if FFMPEG.EXE has been updated in the past 3 years to correct two major problems with it back at that time, described next.

(2) That included version of FFMPEG.EXE from 3 years ago had TWO SUPER-PROBLEMATIC FLAWS:

(a) it only handled audio with frequencies 12kHz or below, completely ignoring "treble" frequencies above 12kHz. This made the resulting output audio very bass-heavy and unnatural, due to its lack of treble above 12kHz.

(b) there seemed to be a swapped mishandling of two pairs of input audio channels (i.e. 3/4 and 5/6, which are supposed to be C/LFE and Ls/Rs respectively). The mistake was that without specifying the "channelmap" operand to control things, the input 3/4 channels (C/LFE) actually produced the output 5/6 channels (Ls/Rs), and the input 5/6 channels (Ls/Rs) actually produced the output 3/4 channels (C/LFE). Clearly this did not sound good.

Hence the command I show above, which actually DID work and properly route all six input AC4 audio channels to the correct output AC3 audio channels. It sounded at least sonically correct, albeit "bass heavy" as I mentioned.


I don't know if the issues with FFMPEG from 2+ years ago (and as included with VideoPlayer) have been addressed and corrected. As I recall there certainly was a big kerfuffle at the time because the author of the FFMPEG modifications wanted to get paid to "complete the coding work" and handle the rest of the frequencies above 12kHz, in contradiction to open-source "free" concepts. I may not be entirely correct or up to date on that story, but there's no question about the fact that the FFMPEG.EXE was "defective" in that regard.

Others may know more about how this story evolved over the past few years.

[emveepee]

At the time when I was playing with this and trying to use TS recordings made by NextPVR from my Flex-4K tuner. NextPVR itself did not handle AC4 audio.

That's not correct. NextPVR backend doesn't care about codec so there is no issue recording AC-4 (DRM is another question). There are NextPVR clients for Android, Windows and Linux including the RPi that do have the ffmpeg patch so they do have audio. Also NextPVR can post process all recordings to use the patched ffmpeg which creates them mp4 or ts file for you. It is actually pretty fast.

Of note this is not a pure patch and not the same as real AC-4 there are several weaknesses. NextPVR clients for Android and Roku also support native AC-4 if the device is h/w compatibility so using good clients is better the using ffmpeg.

Martin

[hdmkv]

Thanks @DSperber. Not long after I posted the solution I re-found above, noticed the audio channels being wrong. Will try your method.

[DSperber]

At the time when I was playing with this and trying to use TS recordings made by NextPVR from my Flex-4K tuner. NextPVR itself did not handle AC4 audio.

That's not correct. NextPVR backend doesn't care about codec so there is no issue recording AC-4 (DRM is another question). There are NextPVR clients for Android, Windows and Linux including the RPi that do have the ffmpeg patch so they do have audio.

My mistake. You are correct. I mangled my comment, conflating NextPVR (that does the DVR recording) with UIDroid (client for playback) etc.

I really did mean to say that the DVR recording itself could not be played back, i.e. that it was the CLIENT which was at fault in not being able to handle AC4. And that was still part of my playing around and experimenting back then.

In passing I mention that I actually have abandoned it all from that Android world, including my NVidia Shield Tube device itself which was the only Android-based hardware I had that could support apps (both through the Google Play Store as well as side-loaded by ADBLINK2). I required "frame-rate matching" using Refresh Rate or built-in feature of apps or OS if possible, and my frustrations with everything that happened on the Shield after upgrading to Android 9 were in the end insurmountable or just unacceptable after putting out my best efforts to accommodate.

Today I remain only with my Roku Ultra (which has its own frame-rate matching restrictions on apps) and ATV4K (which seems to be the closest thing to "perfect frame-rate match, both integer and non-integer). Of course the ATV4K doesn't support AC4, again complicating my life if I want to use HDHR and Flex-4K. I am not well with the "cloud-assisted AC4 decoding" and down-mixing to stereo. I insist on native 5.1 AC4 decoding, producing native 5.1 output as either AC3 or LPCM.

Also NextPVR can post process all recordings to use the patched ffmpeg which creates them mp4 or ts file for you. It is actually pretty fast.

I believe I worked on this back then as well, but in the end was totally unable to get this post-process concept and functionality to work as it should. I just never found any instructions or "recipe" that educated me sufficiently and gave me adequate procedural step-by-step guidance that I could understand and follow and that led to eventual success. That's why I pursued this command-line approach, that at least I could comprehend.

Of note this is not a pure patch and not the same as real AC-4 there are several weaknesses. NextPVR clients for Android and Roku also support native AC-4 if the device is h/w compatibility so using good clients is better the using ffmpeg.

Understood. Even trying to use HDHR client on Roku Ultra (and I have both 4670 which does not support AC4 and 4800 which does support AC4) is a very complicated world for us users.

==> I want the problem to be solved by the vendor, so that I can simply buy whatever hardware I need (even if that includes one network/gateway device along with one additional device PER TV, which is perfectly fine with me) and have it just work. Period. I don't want to get involved, and have to be a tech-savvy scientist to watch TV. I just want the hardware vendor to solve 100% of any and all problems for me, be they hardware, software, codec, licensing, etc. That's what I want, and I will be glad to pay for it. DRM or non-DRM. Live-view or DVR record/playback. TV or AVR/TV. Record once / watch anywhere, at any TV in my house. Start playback here / continue playback there. Whole-home DVR. I want it all. And I want to buy it from a vendor who will sell it to me. And I will pay for it. I don't want to engineer it myself.

All issues and any and all environmental or network differences or requirements are ALL taken into account by that "vendor-provided client/server hardware/software architecture, with network gateway tuner and then one hardware device per TV if that's what it takes", absolutely including built-in AC4 decoding guaranteed so that I get sound no matter. Picture without sound is of course unacceptable.

And I want to be able to hear sound through my AVR (if that's what I'm using for that TV location) or directly from any directly HDMI-connected TV, and it doesn't have to be "transcoded from lossy source AC4 into a new lossy output EAC3". Why do I need TWO lossless encodings to make the sound worse? It can be decoded just once from the lossy source 5.1 AC4 into perfectly acceptable 5.1 LPCM for delivery to the AVR.

And I don't care if its from ATSC 1.0 or 3.0 channels, DRM or non-DRM. It's a TV channel and should automatically deliver picture and sound. That's all I want to know about. And my purchased hardware system should deliver that to me... best possible picture and sound, no matter what I'm watching.

And that is precisely why I have "wandered into" another alternative vendor ATSC 3.0 "one-device-per-each-TV solution" (which includes built-in licensed Dolby AC4 codec support that produces one-time decoding into output 5.1 LPCM for delivery to AVR), given that the Flex-4K I bought over 2 1/2 years ago has still not "delivered" an acceptable software/hardware "enhancement" and/or additional "gizmo hardware product" that will fully solve my desires and objectives, for OTA picture and sound anywhere in my home, on any TV or TV/AVR, live-view or DVR playback, DRM or non-DRM content.

I know it's not easy. But still...

(sorry for the rant. Very frustrated with Flex-4K and DRM. Can't help myself.)