Cavernize 1.6 - Incorrect channel mapping.

[voidxh]

Cavernize 1.6 - Incorrect channel mapping.

[VoidXH]

why does the 5.1 rear created by Cavernize play both the front and rear speakers at the same time?

Because the input was 5.1 side, and side can be rendered on a 5.1 rear system by playing the sound from both. 5.1 side is the correct option for transcoding 5.1 without modification.

ffmpeg defaults to 5.1 rear for 5.1 channel layout

FFmpeg has no default layout in case of WAV, it just copies the channels, but if the order is not correct, it swaps them around. Yes, WAV without metadata defaults to 5.1 rear, but it's because of a misunderstanding at around 2003. The first 8 channels in its channel map are FL, FR, C, LFE, BL, BR, SL, SR, and with metadata, BL/BR can be skipped, which is why you need manual metadata for setting up correct side surround.

This was created in a wrong way because early PC 5.1s were made by engineers who were not involved with cinema, and they had a different channel placement in mind than what movies needed. Movies however were 5.1 side, and Dolby/DTS codecs actually don't even support 5.1 rear, only 5.1 side. For cinema, 7.1 added the rear surrounds, while for PC, it added the sides. This correction is handled differently by FFmpeg and Cavern. FFmpeg doesn't care about which 5.1 you use, it will always copy without any mixing if you don't add filters, even if you convert a 5.1 side content to 5.1 rear. Cavern reads the metadata and places the sources accordingly: if there is metadata (which is not there in your content), it places them accordingly, and if there's no metadata, it assumes it's 5.1 side, which is correct for your content.

[VoidXH]

This is not incorrect. Standard 5.1 is using side speakers, and 5.1 rear can only provide side surround while running both the fronts and rears.

[bluewidy]

I see. Then I want to make a feature request. Is it possible to add a 5.1 rear option to a render target that doesn't play the front?

[VoidXH]

It's 5.1 side.

[bluewidy]

I already tried the 5.1 side. It definitely doesn't play the front, but there's a problem. The original sound does not place the speakers on the side. It is placed in the rear and at the same time does not play the front speakers.

What I don't understand is why the result is playing the rear and front speakers simultaneously. The original does not play both at the same time.

[VoidXH]

Because the original is a standard 5.1 side setup. The speakers are angled in 90-110 degrees, which is more side than rear. 5.1 rear puts the surrounds at a 150 degree angle. For movies, only 5.1 side exists, and 5.1 rear was made for early PC games.

[bluewidy]

Then, I would like to make a feature request. Is it possible to add a 5.1 side tilted 90-110 degrees to the render target?

[VoidXH]

You have an option for it, but I don't recommend it. To do this, open the Cavern Driver, set it to 5.1 surround (it's exactly the angles you want), and set Cavernize to Cavern Driver. It will break the sound, as the files don't conform internally to this layout. All files use the corners and side centers of the room, you can see this by loading Atmos content in Cavern Driver. Dolby is using 45/90 degrees instead of 20-30/90-110, as it's way easier to work with in the renderer. All AVRs also render this way. When Cavernize loads the files, it will put them at Dolby's locations (in the front corners and side centers), to achieve spatial equivalence with Atmos. It will only sound the same as the input, if you use 5.1 side for 5.1 content, and this is correct by standard. If you move the speakers behind in Cavern Driver, it will start to add more and more to fronts, as the objects are between the two. Recommended speaker layouts, like the one seen in your video, were never meant to mimic the space encoded in the files, the two layouts are different.

[bluewidy]

Ah... I see. I thought of another alternative. I'll just use ffmpeg to perform 5.1 pcm encoding. This gives the same angle as the original.

[VoidXH]

FFmpeg works exactly the same way if you set Cavernize to 5.1 side, it just doesn't think about angles, instead it has standard matrices. Both result in the same output.

[bluewidy]

Both result in the same output.

It's not the same.

ffmpeg_pcm_ecode.mp4

[VoidXH]

Compare it with 5.1 side, not 5.1 rear.

[bluewidy]

Oh, I'm sorry. I missed the need to extract to the 5.1 side, not the 5.1 rear. As you said, the two are identical.
But what I am curious about is that the alphabet has changed.
BL -> SL
BR -> SR

compare.mp4

[bluewidy]

Wait... BL and BR are 5.1 rears. Right? Then, as you can see from the video, FFMPEG creates 5.1 rear and does not play front speakers. On the other hand, the 5.1 rear created through Cavernize is playing the front speakers together.

[VoidXH]

FFmpeg creates unmarked 5.1 files as default. It's up to the player what to write in this case, but the correct is side. MPC-HC says side correctly, but VLC is completely broken and actually mixes the center to the left side. They're originally called surrounds and not sides, but in the WAV spec, they're sides.

[bluewidy]

I see. Thank you for always sharing your knowledge.

[bluewidy]

By the way, I missed the crux of my question yesterday, why does the 5.1 rear created by Cabanize play both the front and rear speakers at the same time? Take a look at my waveform picture. The photo shows the 5.1 track provided by the original video. There is no timeline with front and rear speaker tracks coexisting.

and According to the ffmpeg wiki, ffmpeg defaults to 5.1 rear for 5.1 channel layout. If I want a 5.1 side I have to explicitly use a parameter for the layout. and as you can see through the video in my Google Drive, they do not use the front and rear speakers at the same time.
https://drive.google.com/file/d/1TJT9WdL_T0JGPsWb_M99sFyc8b6Sqi2X/view?usp=sharing

[bluewidy]

we recently fixed

You used the expression 'we'. Are you one of the people involved in the development of ffmpeg?

[bluewidy]

Nice! Nice to meet you, developer. I have a matter to report to you. This is something I recently posted on the ffmpeg bug tracker. Could you please take a look at this?
https://trac.ffmpeg.org/ticket/9996

[bluewidy]

Oops... I never imagined he would be you 😆