3.0.0.74 REMUX-ONLY "NO AUDIBLE AUDIO" defect now explained

[DSperber]

Since the "memory leak" I reported with 3.0.0.73 running in REMUX-ONLY mode has now been fixed in 3.0.0.74, I am starting a new thread to describe the new defect symptom produced by 3.0.0.74 running in REMUX-ONLY mode: "NO AUDIBLE AUDIO". This defect from 3.0.0.74 running in REMUX-ONLY mode has already been reported to VSO, but an ETA on a fix is unknown.

Note that this 'NO AUDIBLE AUDIO" occurs when playing the actual movie title (either from the BluRay folder via software, or from the burned BluRay disc in a mechanical player). In fact there actually IS audible audio hear when the main menu is displayed on the screen. This is actually a special 30-second musical intro (in the case of my own one test MP4 file). It produces its own unique 00001.M2TS file, which CXtoHD constructs with PID x1100 information data fields correctly populated, in my case to show 2-channel PCM audio.



Also note that 3.0.0.74 has been proven to crash in REMUX-ONLY mode when attempting to convert two or more input MP4 files. This crash has now been duplicated by VSO support, and they say they are working on a resolution. So my "NO AUDIBLE AUDIO" symptom is produced from REMUX-ONLY mode when using only ONE INPUT MP4 file, so that the program can actually finish without crashing.

==> BOTTOM LINE: it currently appears impossible to run CXtoHD 3.0.0.74 in REMUX-ONLY mode (i.e. "direct copy" of both audio and video, retaining 100% original source quality in the output) and still achieve successful results. The only way to obtain usable results is to accept some type of re-encoding of input to output, either at least re-encoding the audio if not also re-encoding the video.


Specifically, a REMUX-ONLY mode conversion for both audio and video will produce a LOG that looks as follows:



This is the result of project settings for video as follows:






Whereas if REMUX-ONLY is performed for video (i.e. direct copy 100% of original source video) but re-encoding the audio, now the LOG looks as follows:




My own research has now revealed the explanation for the "NO AUDIBLE AUDIO" symptom. I obviously cannot fix the program itself, but at least I can pinpoint the precise reason why there is NO AUDIBLE AUDIO. And that reason is that the critical PID x1100 information (describing audio characteristics inside the 00000.M2TS title) IS NOT BEING POPULATED PROPERLY!! It appears to be entirely missing all fields in the PID x1100 layout, where the presence of valid data is absolutely critical to BluRay players (both hardware and software) in order to correctly decode the imbedded audio stream.

This same PID x1100 information is supposed to be present in the CLPI (clip information) files in the BluRay folder, but is apparently also absent here as well as in 00000.M2TS.

NOTE: with only one single project settings change, forcing audio re-encoding to EAC-3 (while still running "direct copy" REMUX-ONLY mode for video) , now the crucial PID x1100 information IS CORRECTLY POPULATED IN THE OUTPUT 00000.M2TS, and in fact now there IS AUDIBLE AUDIO in the ouput, using both a software BluRay player as well as a physical mechanical disc player!!




Here is what has been revealed by my discoveries, i.e. my "proof".

(1) Attempting to open 00000.M2TS with VideoRedo TV Suite 6 (VRD) to investigate audio/video properties and information, two different results are obtained depending on whether the "defective" file is used (with no PID x1100 information present, from REMUX-MODE of audio as well as video) or whether the "perfect" file is used (with the crucial PID x1100 information present, from RE-ENCODING OF AUDIO along with REMUX-MODE of video).

Here is the output from the unsuccessful attempt to look at the "defective" version of 00000.M2TS using VRD:



In contrast, here is the proper successful output from looking at the "perfect" 00000.M2TS using VRD. Note the presence of the crucial PID x1100 for audio:




(2) The BluRay folder can be examined using BDEdit, which provides details about the contents. In particular the description of audio is displayed in the CLPINF (clip information folder) files.

Here is the output from BDEdit when looking at the "defective" version of 00000.M2TS, i.e. the one without the critical PID x1100 data:



In contrast, here is the proper output from BDEdit when looking at the "perfect" 00000.M2TS. Note the presence of the crucial PID x1100 information describing the 6-channel EAC-3 DD5.1 audio:

[DSperber]

NOTE: even though in theory, the AUDIO setting option to force re-encoding to EAC-3 has been checked, I do not believe any re-encoding is actually occurring at all!! And this must be because the input audio is discovered to already be EAC-3, so that no actual re-encoding is required.

And yet, the critical PID x1100 information appears to get correctly populated, simply by checking the "convert audio to EAC-3" option. Apparently the program's logic path when this option is checked will finish by producing the crucial PID x1100 information... even though no actual re-encoding has been performed, since it actually wasn't necessary (at least in my current test situation where EAC-3 DD5.1 audio is already present).

Obviously the "bug" in 3.0.0.74 when REMUX-ONLY mode is specified for audio as well as video is that the final crucial step of populating PID x1100 has accidentally been bypassed. That's seemingly all it takes, because otherwise the two 00000.M2TS files are actually apparently 100% identical, but for the PID x1100 data.

The size of both 00000.M2TS files is precisely the same 5,526,546,432 bytes. That implies to me that both the underlying audio and video streams must be identical, and not that the "perfect" one has had its audio re-encoded to something other than 100% original audio data.

Here is the REMUX-ONLY \BDMV\Stream folder (with no chapters):



And here is the RE-ENCODE AUDIO \BDMV\Stream folder (with chapters every 5 minutes):



Yes, the PID x1100 information fields may be populated correctly in one 00000.M2TS and omitted or empty or missing in the other 00000.M2TS, but the physical size and structure of these two M2TS files is absolutely the same, so it would seem. This tells me the audio portion must have simply been "direct copied" and not actually re-encoded.

==>> If my theory is correct and in fact the output audio is actually 100% the original input audio, even though I've checked "force re-encode the audio to EAC-3", then checking this option appears to be a way to overcome the otherwise defective 3.0.0.74 which fails to insert the crucial PID x1100 data when performing a full REMUX-ONLY run (for both audio and video). It looks like with this option checked, the program discovers at run time that no conversion is needed since the input is already in the desired output format so that a simple "direct copy" is actually performed!

In other words the program has been tricked into overcoming its own REMUX-ONLY (for both audio and video) bug, by telling it to re-encode the audio but which is then discovered to be unnecessary. However crucially, the logic path within the program now DOES POPULATE PID x1100 DATA PROPERLY, which now results in AUDIBLE AUDIO... while still retaining 100% original audio with no re-encoding after all!!

VSO still needs to fix this to make it work properly even without checking that "force re-encode of audio" option.

[DSperber]

I have been able to use another BluRay creator product successfully, to accomplish a similar REMUX-ONLY mode conversion (again, just using one input MP4 file). The program I used was AVCHDCoder. Obviously the titling and main menu of AVCHDCoder is different than that produced by CXtoHD, so the total file size of 00000.M2TS is slightly different. But otherwise, very very similar output.

But the results out of AVCHDCoder are essentially identical, in that the critical PID x1100 information is again present.

Output from BDEdit for the AVCHDCoder version of 00000.M2TS. Again, notice the presence of the PID x1100 data:



And the output from VRD for this 00000.M2TS:




What is most significant is that the underlying audio imbedded inside the original MP4 file was 362MIB:



Here is the VRD properties for the original MP4 file:



And here is the VRD properties shown for the original MP4 file after being re-muxed into M2TS by VRD:




And the identical 362MIB audio stream size was also identified within the 00000.M2TS produced by CXtoHD (with "forced re-encode audio"):



and the same 362MIB audio stream size was produced in 00000.M2TS created by AVCHDCoder: