Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible bug in 5.1 encoding #30

Open
bmcfee opened this issue Dec 1, 2021 · 5 comments
Open

Possible bug in 5.1 encoding #30

bmcfee opened this issue Dec 1, 2021 · 5 comments

Comments

@bmcfee
Copy link

bmcfee commented Dec 1, 2021

Hey folks, I've been banging my head against a transcoding issue with 5.1 multichannel recordings, and I'm reasonably sure that it's down to an error in either oggenc or libvorbis. TLDR is that the last channel (surround-right) is corrupted.

I'm working with the following recording: https://freesound.org/people/Bokir26/sounds/383922/ but other recordings from different sources (eg https://freesound.org/people/ToXXuS/sounds/591235/ ) demonstrate the same behavior.

I first noticed the erroneous behavior when using sox to convert:

sox 383922__bokir26__commuter-train-03-traffic-jakarta-indonesia.wav 383922__bokir26__commuter-train-03-traffic-jakarta-indonesia.ogg

and the behavior replicates when using oggenc directly, both with version 1.4.0 (provided by ubuntu) and 1.4.2 (built locally from source):

oggenc 383922__bokir26__commuter-train-03-traffic-jakarta-indonesia.wav -o 383922__bokir26__commuter-train-03-traffic-jakarta-indonesia.ogg

I've also tried working directly from raw format and explicitly setting the channels/rate/bit depth, but no luck there as well.

For comparison purposes, here are spectrogram plots of the original channel 5 and that produced by oggenc:
image

And as a baseline, channel 0 looks as follows:
image

Channels 0-4 (front left/right/center + LFE + surround-left) all seem unaffected, so it seems unlikely to be some kind of byte-ordering or interleaving bug.

Flac encoding via sox does work fine (all channels preserved), so I don't believe there are any problems with the input audio.

Additionally, if I discard the last channel when transcoding (using sox [infile] [outfile] remix 1 2 3 4 5) everything works as expected. Similarly, if I skip a channel (eg discard the LFE channel 4: sox [infile] [outfile] remix 1 2 3 5 6), there is no corruption. It seems to be a fundamental issue with generating more than 5 channels: replicating channel 1 6 times (remix 1 1 1 1 1 1) triggers the error, but only on the last channel: the first five are preserved.

(Yes, I know this is not the sox repository: I'm only using sox to easily generate test cases that break things in controlled ways.)

Anyone have a hunch about what's going on here?

@bmcfee
Copy link
Author

bmcfee commented Dec 1, 2021

Quick follow-up: it also works fine if I add an empty seventh channel (?!) remix 1 2 3 4 5 6 0. (Or replace 0 by 1-6 to mix all channels as a seventh output). There seems to be something magically wrong with 6-channel output.

@xiphmont
Copy link

xiphmont commented Dec 1, 2021 via email

@bmcfee
Copy link
Author

bmcfee commented Dec 14, 2021

I don't at all want to pester incessantly 😁 but am checking in to see if there's any update / confirmation of this one?

@bmcfee
Copy link
Author

bmcfee commented Apr 23, 2022

Hey, just checking back to see if there's been any progress on confirming this?

@bmcfee
Copy link
Author

bmcfee commented Sep 29, 2022

Checking in again to see if anyone's been able to confirm or update this one?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants