Support forum for DG Tools

Posted: **Sat Jul 18, 2020 3:53 pm**

Hi Rocky!

I'm sorry if this has been addressed before, but I couldn't find.

When demuxing a BD with a 5.1 PCM track and comparing to EAC3TO and FFMEG results, the .w64 files had the same size but were identical. When checked them in Audacity I found out the channel placement was different. On DGDemux the LFE was the bottom channel while in EAC3TO and FFMEG it's the middle channel. I've placed an image comparison bellow.

https://screenshotcomparison.com/comparison/4607

So my questions are:
1) Does this affect AVR propper channel assignement during playback in any way?
I'm currently without a home theater to check this out

2) Any particular reason why this happens?

Thanks a lot for all the great support and tools!

Posted: **Sat Jul 18, 2020 4:38 pm**

BDgeek2 wrote: ↑
Sat Jul 18, 2020 3:53 pm
When demuxing a BD with a 5.1 PCM track and comparing to EAC3TO and FFMEG results, the .w64 files had the same size but were identical.

Did you mean to say "not identical"? Please try to be precise so I don't fly in circles trying to figure out your posts.

To be honest I haven't look at channel placement. I can do that but it will have to wait for the known issues to be resolved. I also don't know much about Audacity. Let me know what you find when you get a chance to test things. I can tell you that I am using WAVFORMATPCM while EAC3TO uses WAVEFORMATEXTENSIBLE.

Posted: **Sat Jul 18, 2020 7:20 pm**

Sorry, what I mean by idential is that I can use a software like Windiff to CRC files and check if they are bit for bit identical. That happens for instance when I demux a DTS-HD MA file with both DGDEMUX and EAC3TO. Windiff indicates the resulting files are identical.

In the case of .w64 files, since both outputs had the same size, meaning they at least the same exact lengh as bitrate is constant, I decided to check them out in Audacity to see if something weird was going on with the wave forms. Tha's when I realized they had different channel placement, but the wave forms are indeed identical, as it's to be expected.

In all my experience, decoding multichannel formats like AC-3, DTS, DTHD (even Atmos) with both eac3to and ffmpeg, all of them result in the LFE channel coming right after (or bellow in a vertical placement) the center channel and before surrounds (as image comparison I posted before).

Hope I could make it clearer now. Thanks for the effort of looking into it Rocky!

Posted: **Sat Jul 18, 2020 7:44 pm**

Still not clear as you haven't told me what is identical to what.

The order in which things are shown could be down to PCM versus EXTENSIBLE. Let us know when you are able to test things.

Posted: **Sun Jul 19, 2020 5:55 pm**

Rocky,

the real point I'm trying to make is that when demuxing Multichannel PCM, the demuxed track of DGDMUX has a different channel assignment than the demuxed track of all other programs I have tried (EACTO, TSMUXER and FFMPEG), which all have equal channel assignements.

My concern is if this might might cause any problems when playing back on Home Theater equipment (decoded by consumer AVR). Unfortunately, I won't be able to test muxes on a Home Theater AVR for quite a while.

______

The "identical" thing is beside the point, it was just me trying to explain how I got to figure out the channel placement issue. But I'll try again:

Take for instance any BD or UHD with a DTS-HD MA track and one with a PCM multichannel track (single file, no branching). Or better yet, one like Kill Bill Vol. 1 or 2 UK which has both a DTS-HD MA 5.1 track and a PCM 5.1 track on the same disk.

If I use a checksum (CRC) program like Windiff to compare the demuxed tracks of DGDEMUX with the respective demuxed tracks obtained by using any of the other afore mentioned programs, the files are labeled as indentical (like bit por bit copies) in the case of the .dtshd but not in the case of .w64 files.

In other words, the demuxed .dtshd track of DGDEMUX was labeled identical to the demuxed .dtshd track of eac3to (or TSMUXER and FFMPEg for that matter) by the file comparison program Windiff (https://en.wikipedia.org/wiki/WinDiff), which is freeware and pretty easy to obtain.

The same result does not happen when I compared the .w64 files. That's what rang a bell and made me try to investigate it a little further.

To be honest the resulting .w64 files of EACTO and FFMPEG are not initially labeled identical by Windiff either. But that's probably due to diffeent versions of encoder being used, because once I run the output .w64 of one of these programs through the other, then the output file is now labeled identical by Windiff to the original file demuxed with said program.

In other words, if I take the demxued .w64 of FFMPEG and run it throught EAC3TO with output also set to .w64, the resulting file is now labelled identical (by Windiff) to the .w64 orginally demuxed from the disk by EAC3TO.

This "fix" does not work with DGDEMUX .w64 output, because channel placement is now locked and doesnt change back even if ran through EAC3TO or FFMPEG.

Tried my best to make it clearer now. I'm not a native english speaker and not at all versed in program coding.

Posted: **Sun Jul 19, 2020 6:35 pm**

BDgeek2 wrote: ↑
Sun Jul 19, 2020 5:55 pm
the demuxed track of DGDMUX has a different channel assignment than the demuxed track of all other programs

How do you know that? Does Audacity label them as L, R, LFE, etc.? I'm not going to start a research project to address your "concerns". Demonstrate an issue and I will look at it.

I know things are different from other programs because I use a different W64 wrapper, which I said a couple times.

Posted: **Fri Jul 24, 2020 6:19 am**

I'm tebasuna51 in Doom9.

I can confirm the bug with LPCM in DGIndexNV when demux LPCM tracks.
EDIT: the same with DGDemux.
Tested with a channel test to be easy to identify.

Is know than LPCM tracks are stored inside m2ts with data in Big Endian format and LFE channel at end.
When eac3to (like I say to madshi) or ffmpeg convert LPCM tracks, to wav or w64, do the change to Little Endian and remap the last channel (LFE) to the 4º channel (5.1 or 7.1) like need wav or w64 formats.

Seems the endian change is correct but without the LFE remap.

Posted: **Fri Jul 24, 2020 8:23 am**

Hello Guest 3. Thank you for your message.

So for 5.1 we remap like this:

L,R,C,BL,BR,LFE --> L,R,C,LFE,BL,BR

and for 6.1:

L,R,C,BC,SL,SR,LFE --> L,R,C,LFE,BC,SL,SR

and for 7.1:

L,R,C,BL,BR,SL,SR,LFE --> L,R,C,LFE,BL,BR,SL,SR

Did I get that right? The rule seems to be move the last channel to the fourth channel and slide the others down by one.

Posted: **Fri Jul 24, 2020 8:42 am**

About wav format (the same for w64 with only the header is different) you can see http://www-mmsp.ece.mcgill.ca/Documents ... /WAVE.html and the Microsoft document http://www-mmsp.ece.mcgill.ca/Documents ... chaudP.pdf

You can see than the audio samples data are stored in Little Endian order and channels in the order FL,FR,FC,LFE,... (4º in 5.1 and 7.1 channels config)

For LPCM audio stored in BD's or DVD's you can see https://wiki.multimedia.cx/index.php/PCM#DVD_PCM for audio samples stored in Big Endian order.
I can't found now a relevant spec about the channel order (I will search), then belive in me, and eac3to, ffmpeg, and other developers, when I say you must remap the last channel in LPCM to the 4º channel in wav/w64 in LPCM 5.1 or 7.1 (I only see LPCM 2.0, 5.1 in DVD's or/and 7.1 in BD's)

I don't see LPCM 6.1 in DVD's or BD's, I will make some test, in the mean time try with:

L,R,C,BL,BR,BC,LFE --> L,R,C,LFE,BL,BR,BC

I doubt it was:

L,R,C,BC,SL,SR,LFE --> L,R,C,LFE,BC,SL,SR

because when LPCM in DVD's BD's is defined the BL,BR pair is preferred, the SL,SR pair preference for surround channels is posterior.

If you have a sample LPCM 6.1 let me know.

Posted: **Fri Jul 24, 2020 9:35 am**

Thank you, Guest 3!

Posted: **Fri Jul 24, 2020 10:19 am**

Can y'all test this please? Thank you. Implemented for 5.1 and 7.1 LPCM to W64. It plays but I don't know how to verify the channel placings.

http://rationalqm.us/dgdemux/binaries/DGDemux_remap.exe

Posted: **Fri Jul 24, 2020 12:06 pm**

5.1 is ok.

But 7.1 is remaped to: FL,FR,FC,LFE,SL,BL,BR,SR

Posted: **Fri Jul 24, 2020 12:23 pm**

Can you double check that? I don't see any such thing in the code.

Code: Select all

		unsigned char t[3];
		p = audio[index].pcm_buffer;
		while (p < (audio[index].pcm_buffer + num_to_write))
		{
			memcpy(t, &p[size * 7], size);
			memcpy(&p[size * 7], &p[size * 6], size);
			memcpy(&p[size * 6], &p[size * 5], size);
			memcpy(&p[size * 5], &p[size * 4], size);
			memcpy(&p[size * 4], &p[size * 3], size);
			memcpy(&p[size * 3], t, size);
			p += size * 8;
		}

size is 2 for 16-bit and 3 for 24-bit.

Posted: **Fri Jul 24, 2020 1:42 pm**

The code seems ok.

I tried with other tsMuxeR version, loading the wavs like pcm, ... and always the same remap.

The demuxed wav with tsMuxeR, eac3to and ffmpeg have the channels ok

Maybe there are some problem with how tsMuxeR store the data.
Can you make a DGIndex version to check the problem over mkv's?

EDIT:
I check the previous DGDemux version and the problem was already present, the 7.1 output was:

FL,FR,FC,SL,BL,BR,SR,LFE

EDIT 2:
the wrong map is the same in DGIndex with the m2ts, but with mkv the problem is the wav header:

Code: Select all

File ........: C:\tmp\00000_track4_eng_DELAY 0ms.wav
Size ........:  16126100 bytes

---------------------------------------------- Header Info
ChunkID .....: RIFF
RiffLength ..:  36 (ERROR: Must be Size - 8 = 16126092)
Container ...:  WAVE
SubchunkID ..: fmt  (Length: 16)
AudioFormat .:  1 (Integer)
NumChannels .:  8
SampleRate ..:  48000
ByteRate ....:  1152000
BlockAlign ..:  24
BitsPerSample:  24
SubchunkID ..: data (Length: 0)
Offset data .:  44 (WARNING: Extrachunks at end of file: 16126056 bytes)
Duration ....:  0 sec., (0h. 0m. 0s.)
------------------------------------------------- End Info

The RiffLength and DataLength are wrong, but corrected the wav is correct, also the channels map.

Posted: **Fri Jul 24, 2020 5:32 pm**

OK, I was wrong about the order on bluray. This is what we need:

bluray --> W64
L R C BL SL SR BR LFE --> L R C LFE BL BR SL SR

Numbering channels 0-based, need to do:

7->3
6->5
5->7
4->6
3->4

So please re-download DGDemux_remap.exe and test that. Thank you.

The original DGDemux order should be the same as bluray order, but that doesn't match what you say above, so we may need further changes depending on your testing.

After bluray is squared away, I'll look at MKV for DGIndexNV.

Posted: **Fri Jul 24, 2020 6:22 pm**

Now you obtain L R C LFE SL SR BL BR

EDIT:
I checked my code in NicAudio.dll :

Code: Select all

                bIsBluRay = true;
                Bytes = SampleBits / 8;          // Bytes only auxiliar here to prepare the matrix
                // Initializing remap matrix
                for (Channels=0; Channels < ChannelCount; Channels++) map[Channels] = (Channels + 1) * Bytes;
                if (ChannelCount > 5) {
                         map[ChannelCount - 1] = 4 * Bytes;  // LFE from last to fourth
                         map[3]                = 5 * Bytes;  // BL to fifth
                         map[ChannelCount - 2] = 6 * Bytes;  // BR from penultimate to sixth
                }
                if (ChannelCount > 6)   map[4] = 7 * Bytes;  // SL or BC
                if (ChannelCount > 7)   map[5] = 8 * Bytes;  // SR

And is correct for me the:
bluray --> W64
L R C BL SL SR BR LFE --> L R C LFE BL BR SL SR

And I think the remap can be:

Code: Select all

       memcpy(t, &p[size * 7], size);              // t = LFE
       memcpy(&p[size * 7], &p[size * 5], size);   // 7 <- SR  5
       memcpy(&p[size * 5], &p[size * 6], size);   // 5 <- BR  6
       memcpy(&p[size * 6], &p[size * 4], size);   // 6 <- SL  4
       memcpy(&p[size * 4], &p[size * 3], size);   // 4 <- BL  3
       memcpy(&p[size * 3], t, size);              // 3 <- LFE 7

Posted: **Fri Jul 24, 2020 8:58 pm**

Thank you. Just got back from swimming and I'm pooped out for today. I could just shuffle as you say but I want it to be derivable from specs. And my code is already doing what your suggested code is doing. Continuing in the morning...

You could help a lot by telling me how you are doing your testing to establish the order of my demuxed stream.

Posted: **Sat Jul 25, 2020 5:12 am**

BD_LPCM BD created by tsMuxeR:

eac3to ...TEST_LPCM\BD_LPCM\BDMV\PLAYLIST\00000.mpls 1)
------------------------------------------------------------------------------
M2TS, 1 video track, 2 audio tracks, 0:00:15, 25p
1: h264/AVC, 720p25 (16:9)
2: RAW/PCM, Spanish, 5.1 channels, 24 bits, 48kHz
3: RAW/PCM, English, 7.1 channels, 24 bits, 48kHz

(video/audio not exactly in sync)

Chan_test_51.jpg Image of wav Source 5.1 and extracted by tsMuxeR, eac3to, ffmpeg and DGDemux_remap
Chan_test_71.jpg Image of wav Source 7.1 and extracted by tsMuxeR, eac3to and ffmpeg
Chan_test_71_DG.jpg Image of w64 extracted by DGDemux_remap

You need only load the wav or w64 in Audacity to see the problem.
http://www.mediafire.com/file/84te2q8wz ... CM.7z/file

Posted: **Sat Jul 25, 2020 7:58 am**

Please re-download and test DGDemux_remap.exe. The channel order now matches the other demuxers. I can't derive that shuffling from specs but I suppose as long as it matches the others, gives you what you want, and plays your channel test disk on the right speakers, I'll live with it.

Your test disk can't be demuxed through DGDemuxGUI because the MPLS is too short, but you figured out that you can do it by invoking DGDemux directly through CLI. Bravo.

After you confirm correct channel order, I'll update DGDemux and DGDecNV. Then I will look into MKV LPCM from DGIndexNV.

Thank you, Guest 3, for your great assistance with this issue. I've always been something of a philistine when it comes to audio.

Posted: **Sat Jul 25, 2020 11:25 am**

Yes, is correct now.

Thanks for your job.

Posted: **Sat Jul 25, 2020 11:31 am**

You're welcome, Guest 3. Love working with you. Gonna tell Bullwinkle about it.

Posted: **Sat Jul 25, 2020 11:33 am**

Guest 3 is Moose Approved.

Posted: **Sun Jul 26, 2020 7:18 am**

Fix released in DGDemux slipstream 34. Marking RESOLVED.

Posted: **Tue Jul 28, 2020 1:12 pm**

Rocky wrote: ↑
Sun Jul 26, 2020 7:18 am
Fix released in DGDemux slipstream 34. Marking RESOLVED.

Thanks a lot Rocky for the great and prompt work as always!

I wasn't able to follow the discussions for a few days, due to having house guests, and it's a great joy to see this matter resolved. I also leave a big thanks to Guest 3 for backing it up and breaking down the technical aspect I lack.

Support forum for DG Tools

[RESOLVED] Incorrect LPCM channel order

[RESOLVED] Incorrect LPCM channel order

Re: DGDemux development

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: Possible issue with LPCM channel placement

Re: [RESOLVED] Incorrect LPCM channel order

Re: [RESOLVED] Incorrect LPCM channel order