1

Topic: thd to AAC

Hello,

If I select from the audio stream list the thd part (not the "ac3 core") of the thd stream will Hybrid encode the thd part instead of the ac3 core as assumed?

I have such a question because after encoding to aac Hybrid did a cleanup job for a file with ac3 extension. Or maybe the thd part of the stream is extracted into an .ac3 file as well?

A similar question I would have for the DTS-HD streams. If I select them from the list to encode, will Hybrid encode the complete stream or only the DTS core which is usually/always a ~1536 kbit/s 5.1 stream on BD-s?

I want to encode the HD lossless streams to AAC and not the cores/lossy part of them.

2

Re: thd to AAC

a. iirc Hybrid uses ac3 for both thd and ac3, so you need to look at the command lines to know for sure.
b. Hybrid will use the 'full' stream if the channel count of the full stream is higher. (you often have 7.1 full stream with a 5.1 core)
c. Hybrid will only use the core stream when it things that it is the better choice. smile
-> check the calls yourself

3 (edited by mparade 2017-05-14 17:34:34)

Re: thd to AAC

Selur wrote:

a. iirc Hybrid uses ac3 for both thd and ac3, so you need to look at the command lines to know for sure.
b. Hybrid will use the 'full' stream if the channel count of the full stream is higher. (you often have 7.1 full stream with a 5.1 core)
c. Hybrid will only use the core stream when it things that it is the better choice. smile
-> check the calls yourself

How can one check the command line made by Hybrid? Do I have to make for myself a debug output?
Regarding b. I do not understand why handling streams like this (reencoing the lossy core instead of the full lossless stream even it is only 5.1) is better than reencoding the lossless full stream. Regarding c. I do not understand how reencoding a lossy core could be a better choice than reencoing a lossless full stream.

4

Re: thd to AAC

How can one check the command line made by Hybrid?

disable 'Jobs->Queue->Minimize job command lines' and you can see the calls.

Do I have to make for myself a debug output?

you could do that too

Regarding b. I do not understand why handling streams like this (reencoing the lossy core instead of the full lossless stream even it is only 5.1

Hybrid will prefer the core stream if a downmix is needed/used. Because a professionally done downmix is normally better than what you can archive in Hybrid.

Regarding c. I do not understand how reencoding a lossy core could be a better choice than reencoing a lossless full stream.

example: downmix, dynamic compression, etc.

=> if you thing Hybrid does something in a not so good way and you know a better way let me know and I can try to look into it. (not the next few days)

Cu Selur

5

Re: thd to AAC

Selur wrote:

How can one check the command line made by Hybrid?

disable 'Jobs->Queue->Minimize job command lines' and you can see the calls.

Do I have to make for myself a debug output?

you could do that too

Regarding b. I do not understand why handling streams like this (reencoing the lossy core instead of the full lossless stream even it is only 5.1

Hybrid will prefer the core stream if a downmix is needed/used. Because a professionally done downmix is normally better than what you can archive in Hybrid.

Regarding c. I do not understand how reencoding a lossy core could be a better choice than reencoing a lossless full stream.

example: downmix, dynamic compression, etc.

=> if you thing Hybrid does something in a not so good way and you know a better way let me know and I can try to look into it. (not the next few days)

Cu Selur

Okay. Thank you for the information. At the first stage, I will disable the "Minimize job command lines" in my next encodes and check them.
Above I just wanted to be sure ((I forgot to tell you that I always use "statistically transparent" AAC low-complexity encodes in Hybrid using qaac keeping all number of channels and just in case of HD lossless streams (where I can save a lot of space). In case of lossy audio streams I always keep the original audio stream upto 640kbit/s)) to encode the lossless stream and not the lossy one if the original stream is one of the HD lossless types (TrueHD, DTS-HD, LPCM etc.)

6

Re: thd to AAC

As a side note: using flac would keep the audio lossless and still save a lot of space compared to DTS-HD&Co.

7 (edited by mparade 2017-05-17 20:22:21)

Re: thd to AAC

Selur wrote:

a. iirc Hybrid uses ac3 for both thd and ac3, so you need to look at the command lines to know for sure.
b. Hybrid will use the 'full' stream if the channel count of the full stream is higher. (you often have 7.1 full stream with a 5.1 core)
c. Hybrid will only use the core stream when it things that it is the better choice. smile
-> check the calls yourself

I probably missed something because from the calls I can only see that an extracted .dts/.ac3 file was reencoded using qaac.
I do not see any information if those extracted dts/ac3 files contained "only" the core or the "full" stream.
I just want to be sure to reencode the full stream and not only the core.

P.S: I do not use any downmixing, filtering everything (channel number etc.) I want to keep as it is in the original streams. I just want to reencode them to aac using the tvbr method and highest quality setting.

8

Re: thd to AAC

I do not see any information if those extracted dts/ac3 files contained "only" the core or the "full" stream.

I would need a debug output of the analysis of the source and the job creation to be sure smile

9

Re: thd to AAC

Selur wrote:

I do not see any information if those extracted dts/ac3 files contained "only" the core or the "full" stream.

I would need a debug output of the analysis of the source and the job creation to be sure smile

Please find that as an attachement.

10

Re: thd to AAC

In that debug output you used tsMuxer for the extraction and apparently tsMuxer only extracted the core.
Looking at the code seems like atm. Hybrid always extracts just the core when extracting for a reencode.
-> will send you a dev version which behaves differently in a few minutes. smile
Please test it and report back.

Cu Selur

11

Re: thd to AAC

Selur wrote:

In that debug output you used tsMuxer for the extraction and apparently tsMuxer only extracted the core.
Looking at the code seems like atm. Hybrid always extracts just the core when extracting for a reencode.
-> will send you a dev version which behaves differently in a few minutes. smile
Please test it and report back.

Cu Selur

Do you mean in case of DTS-HD it only extracts the DTS core (1536kbit/s) , in case of TrueHD it only extracts the ac3 core (640kbit/s)?

12

Re: thd to AAC

Yes, when tsMuxeR is used and the audio is reencoded.
Side note: for TrueHD it's not really a core. Unlike with DTS-HD the ac-3 part isn't required for decoding the TrueHD stream. (which is why mkv only allows TrueHD and ac-3 in separate streams)

Cu Selur

13

Re: thd to AAC

Selur wrote:

Yes, when tsMuxeR is used and the audio is reencoded.
Side note: for TrueHD it's not really a core. Unlike with DTS-HD the ac-3 part isn't required for decoding the TrueHD stream. (which is why mkv only allows TrueHD and ac-3 in separate streams)

Cu Selur

Here is the DebugOutput for the "should only extract the core when that is specifically enabled in the gui."
It does no reencoding at all now...extract something (I can't tell if it is the core or the full stream) then clean up right then without reencoding.

14

Re: thd to AAC

According to the debug output is did extract the audio with tsMuxeR and then reencode the audio using:

"C:\PROGRA~1\Hybrid\ffmpeg.exe" -y -threads 12 -loglevel fatal -i "C:\Temp\iId_1_DELAY_-44ms_lang_eng_aid_4352_21_19_59_4010_04.dts" -t 00:00:44.000 -ac 6 -ar 48000 -sample_fmt s32 -f sox - | "C:\PROGRA~1\Hybrid\sox.exe" --multi-threaded --ignore-length --temp "C:\Temp\21_19_59_401005" --buffer 524288 -S -t sox - -b 16 -t raw - | "C:\PROGRA~1\Hybrid\qaac.exe" --threading --raw --raw-channels 6 --raw-rate 48000 --tvbr 75 - -o "C:\Temp\iId_1_aid_4352_lang_eng_21_19_59_4010_06.aac"

(only the first 44 seconds <- my guess is you set it up to only encode 44 seconds)

This audio is probalby the whole thing "C:\Temp\00104.track_4352.dts" (2788.41 MB),...

15

Re: thd to AAC

Selur wrote:

According to the debug output is did extract the audio with tsMuxeR and then reencode the audio using:

"C:\PROGRA~1\Hybrid\ffmpeg.exe" -y -threads 12 -loglevel fatal -i "C:\Temp\iId_1_DELAY_-44ms_lang_eng_aid_4352_21_19_59_4010_04.dts" -t 00:00:44.000 -ac 6 -ar 48000 -sample_fmt s32 -f sox - | "C:\PROGRA~1\Hybrid\sox.exe" --multi-threaded --ignore-length --temp "C:\Temp\21_19_59_401005" --buffer 524288 -S -t sox - -b 16 -t raw - | "C:\PROGRA~1\Hybrid\qaac.exe" --threading --raw --raw-channels 6 --raw-rate 48000 --tvbr 75 - -o "C:\Temp\iId_1_aid_4352_lang_eng_21_19_59_4010_06.aac"

(only the first 44 seconds <- my guess is you set it up to only encode 44 seconds)

This audio is probalby the whole thing "C:\Temp\00104.track_4352.dts" (2788.41 MB),...

No, Hybrid set it for itself up to only encode 44 seconds by incorrectly analysing again the duration of the source.

16

Re: thd to AAC

So you are saying Hybrid indicates that the source is 44 seconds long, because the debug output doesn't show that.
The audio delay seems to be -44ms and the length is 5797.643 seconds, according to the entry in the audio queue,..

D:\BD-50\2D\FEL!\HELIUM_D1_GBR\BDMV\PLAYLIST\00104.mpls;4352;aac;6;quality;75;qaac;low complexity;48000;0.00;eng;-44;5797.624;dts;0;1;don't change;;false;;false;9;false;;;;false;false;;;false;48000;unknown;dts;cvbr;false;true;false;3/2/1.1 / 3/2/1.1 / 3/2/0.1;1/1;;0;0;;None;54:_:15;10;20;0;1000;24;false;;dts-hd;false;1;;;;;2.55;16;none;4;GPU;NVIDIA CUDA;4352;6;false;D:\BD-50\2D\FEL!\HELIUM_D1_GBR\BDMV\PLAYLIST\00104.mpls;true;false;;

-> will try to look into it,...

Got it, I also need to ignore the frame count and calculate it,..

17 (edited by mparade 2017-05-19 18:37:16)

Re: thd to AAC

Selur wrote:

So you are saying Hybrid indicates that the source is 44 seconds long, because the debug output doesn't show that.
The audio delay seems to be -44ms and the length is 5797.643 seconds, according to the entry in the audio queue,..

D:\BD-50\2D\FEL!\HELIUM_D1_GBR\BDMV\PLAYLIST\00104.mpls;4352;aac;6;quality;75;qaac;low complexity;48000;0.00;eng;-44;5797.624;dts;0;1;don't change;;false;;false;9;false;;;;false;false;;;false;48000;unknown;dts;cvbr;false;true;false;3/2/1.1 / 3/2/1.1 / 3/2/0.1;1/1;;0;0;;None;54:_:15;10;20;0;1000;24;false;;dts-hd;false;1;;;;;2.55;16;none;4;GPU;NVIDIA CUDA;4352;6;false;D:\BD-50\2D\FEL!\HELIUM_D1_GBR\BDMV\PLAYLIST\00104.mpls;true;false;;

-> will try to look into it,...

Got it, I also need to ignore the frame count and calculate it,..

The latest version seems to be a lot "better". I attached the DebugOutput for a test encode with THD full stream to AAC.
Analysing of the source seems to be OK, extracting of the THD full stream instead of the core seems to be OK but please confirm because I could not find the size of the extracted ac3 file the second time in the debugoutput (very long).
The only atypical thing I realized is that AAC encoding went to around 110%. Really do not why because Hybrid is reporting the correct duration of source. Now, I am going to test a DTS-HD full stream to AAC encode.

Thanks for the help in advance.

18

Re: thd to AAC

 C:\Users\Bogárdi Mátyás\AppData\Local\Temp\00803.track_4352.ac3 (4769.53 MB)

-> too large for ac3 only

19

Re: thd to AAC

Selur wrote:
 C:\Users\Bogárdi Mátyás\AppData\Local\Temp\00803.track_4352.ac3 (4769.53 MB)

-> too large for ac3 only

NICE! Do not you see any problem with going above 100% during AAC encoding?

20

Re: thd to AAC

Selur wrote:
 C:\Users\Bogárdi Mátyás\AppData\Local\Temp\00803.track_4352.ac3 (4769.53 MB)

-> too large for ac3 only

This one was OK for me. ....mp\00100.track_4352.dts (2613.84 MB) is too big for an 1509.75 kbit/s core only for ~97min of duration.

21

Re: thd to AAC

Here aac encoding went to about 106% and the stream itself is longer than the playlist itself from which it is originated. According to both quicktime player and mediainfo the duration is 1h 45 min.
Correct is 1h 44 min. The percentage of encoding indicates this time difference.

22

Re: thd to AAC

According to the debug output the length is assumed as 6263.215 sec.

AudioID: 4353
Format: truehd / ac-3
Bit rate: 2871
Channels: 6
Sample rate: 48000
Video delay: 0
Language: eng
Length: 6263.215

Which should be 01:44:23.
Nothing more that I can say about that.
May be this is a broken playlist (wouldn't be the first time that a Blu-ray contains 'broken' playlists as some sort of copy protection).

Hybrid extracts the audio using:

MUXOPT --no-pcr-on-video-pid --new-audio-pes --demux --vbr  --vbv-len=500
A_AC3, "D:\BD-50\2D\ATMENT\AZ IGENEMBER\YES_MAN\BDMV\PLAYLIST\00001.mpls", track=4353

and

tsMuxeR "D:\OUTPUT\tsmuxer_17_08_43_8410_01_1.meta" "D:\OUTPUT"

which creates 'D:\OUTPUT\00001.track_4353.ac3' (1640.19 MB) which Hybrid renames to 'D:\OUTPUT\iId_8_DELAY_-44ms_lang_eng_aid_4353_17_08_43_8410_04.ac3' and then converts using:

"C:\PROGRA~1\Hybrid\ffmpeg.exe" -y -threads 12 -loglevel fatal -i "D:\OUTPUT\iId_8_DELAY_-44ms_lang_eng_aid_4353_17_08_43_8410_04.ac3" -ac 6 -ar 48000 -acodec pcm_s16le -f wav - | "C:\PROGRA~1\Hybrid\qaac.exe" --no-delay --threading --tvbr 127 --adts - -o "D:\OUTPUT\iId_8_aid_4353_lang_eng.aac"

which seems fine to me.

Don't see anything that is done wrong by Hybrid.
(no clue why you use tsMuxeR and not ffmpeg like Hybrid recommends, but that is your choice)

Cu Selur

Ps.: btw. if you use 127kBit/s for 5.1 audio, using the thd instead of the ac3-core doesn't seem to make much sense to me. smile
(with such a low bitrate for 5.1 most if not all of the additional data in the thd stream will be lost any way and might hurt the overall quality more than using the ac3 core as base)

23 (edited by mparade 2017-05-20 18:07:29)

Re: thd to AAC

Selur wrote:

According to the debug output the length is assumed as 6263.215 sec.

AudioID: 4353
Format: truehd / ac-3
Bit rate: 2871
Channels: 6
Sample rate: 48000
Video delay: 0
Language: eng
Length: 6263.215

Which should be 01:44:23.
Nothing more that I can say about that.
May be this is a broken playlist (wouldn't be the first time that a Blu-ray contains 'broken' playlists as some sort of copy protection).

Hybrid extracts the audio using:

MUXOPT --no-pcr-on-video-pid --new-audio-pes --demux --vbr  --vbv-len=500
A_AC3, "D:\BD-50\2D\ATMENT\AZ IGENEMBER\YES_MAN\BDMV\PLAYLIST\00001.mpls", track=4353

and

tsMuxeR "D:\OUTPUT\tsmuxer_17_08_43_8410_01_1.meta" "D:\OUTPUT"

which creates 'D:\OUTPUT\00001.track_4353.ac3' (1640.19 MB) which Hybrid renames to 'D:\OUTPUT\iId_8_DELAY_-44ms_lang_eng_aid_4353_17_08_43_8410_04.ac3' and then converts using:

"C:\PROGRA~1\Hybrid\ffmpeg.exe" -y -threads 12 -loglevel fatal -i "D:\OUTPUT\iId_8_DELAY_-44ms_lang_eng_aid_4353_17_08_43_8410_04.ac3" -ac 6 -ar 48000 -acodec pcm_s16le -f wav - | "C:\PROGRA~1\Hybrid\qaac.exe" --no-delay --threading --tvbr 127 --adts - -o "D:\OUTPUT\iId_8_aid_4353_lang_eng.aac"

which seems fine to me.

Don't see anything that is done wrong by Hybrid.
(no clue why you use tsMuxeR and not ffmpeg like Hybrid recommends, but that is your choice)

Cu Selur

Ps.: btw. if you use 127kBit/s for 5.1 audio, using the thd instead of the ac3-core doesn't seem to make much sense to me. smile
(with such a low bitrate for 5.1 most if not all of the additional data in the thd stream will be lost any way and might hurt the overall quality more than using the ac3 core as base)

I always use q127 tvbr method with qaac. In this case I am quite sure reencoding the full stream is rational. The bitrate in this case always will much depends on the complexity of the source.
This is meant for "statistically transparent" encodes.

P.S. I have switched to tsMuxer because we had problems with ffmpeg. Don't you remember? smile

24

Re: thd to AAC

The switching to tsMuxeR only was needed for that one source,... but like I said your choice. smile

25 (edited by mparade 2017-05-20 19:59:16)

Re: thd to AAC

Selur wrote:

The switching to tsMuxeR only was needed for that one source,... but like I said your choice. smile

I have problems with tsMuxer only in case of TrueHD sources.
And the files extracted using tsMuxer and ffmpeg are different in sizes, so I think the content is different as well (maybe this is the cause of the difference in duration).

It seems to me that in case of using ffmpeg Hybrid extracts only the independent TrueHD stream itself (which is the correct behaviour).
It seems to me that in case of using tsMuxer Hybrid extracts (the independent TrueHD stream + the independent core stream) and combine them together (only assumption seeing the differences in sizes using the DebugOutput) smile.