Alan Parsons Project - The Turn of a Friendly Card (Box Set in Feb 2023, standalone Blu-Ray in May)

QuadraphonicQuad

Help Support QuadraphonicQuad:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
I just came here to see if anyone else was having the same issue! AudioMuxer shows 24 bit audio, but once it creates the files they're 16 bit. Doesn't matter if I extract to WAV or FLAC.

I don't claim that I can reliably hear the difference, but it's weird and confusing.
I know nothing about AudioMuxer so I can offer no support except to say
I've heard this issue with it before. Maybe post to a AudioMuxer users forum?

The best advice I can give is to try DVD Audio Extractor. It has a 30 day free
trial and a lifetime license with unlimited upgrades is under $40. It is the software
that most others I'm aware of use for this.
https://www.dvdae.com/
 
I just came here to see if anyone else was having the same issue! AudioMuxer shows 24 bit audio, but once it creates the files they're 16 bit. Doesn't matter if I extract to WAV or FLAC.

I don't claim that I can reliably hear the difference, but it's weird and confusing.
I use AudioMuxer to extract FLACs from MKVs too and this is the only disc I have that show 24-bit when spinning the disc on a BD player but 16-bit after FLAC extraction.

I posted on this back on Page 7 of this thread and after a yap with a couple of other QQ members, have come to the conclusion that they're actually 16-bit with 8-bits of zero-value bloat. I can't hear any difference between them when spinning the BD or the HDD.

Probably a mistake and a lack of quality control I reckons. Check your work. Check your work. Check your work. Then get someone else to check your work.
 
Yes and no... The extracted native audio bit-streams are 24-bits. However, some audio re-encoding softwares might elect to remove any superfluous zeros, especially when encoding to Flac.

Personally, I back-up and play the native streams. Ignorance is bliss...
I think you're right SMD. I've never had AudioMuxer downsample anything unless it was as you say.
I believe the author of AudioMuxer, Pl4it, would have corrected it years ago if there was a problem.
However I don't believe he formally supports the program anymore. I've swapped messages with him a few times over the years and he's been willing to make changes at times.
 
It may be the underlying app (in AudioMuxer), eac3to, that is causing the default to 16 bits, not sure. Just not something I want to spend time on.

But yeah, Pl4it doesn't really update the app anymore. It's been a good tool for years, but it has it's limitations. Like many such apps, it draws on other tools to do what it does, and as such bears the limitations of the underlying apps.

* @zeerround ran some tests, I'm waiting to hear his take or he can respond here if he likes/or not.
 
It may be the underlying app (in AudioMuxer), eac3to, that is causing the default to 16 bits, not sure. Just not something I want to spend time on.
I just recently found out the hard way--after screwing up a bunch of albums--that using ffmpeg to concatenate multiple 24 bit files into a single one results in the output file being 16 bit. In fact, it was while researching how many I'd ruined that I discovered this issue with the Parsons disc.

I'm still furious about ffmpeg. I had started using it to get used to it in case SoX, which hasn't been updated in years, goes away. If you tell SoX to concatenate, the output is the same as the input (because why on earth wouldn't it be?), but ffmpeg does its own thing.

I mention it because a lot of the Linux audio processing code seems to be shared and copied amongst different applications (e.g., you can tell ffmpeg to resample using SoX's resampling library), so I suspect you're onto something. Still, it's odd that this is the only disc any of us have encountered that shows this issue.
 
Last edited:
I know nothing about AudioMuxer so I can offer no support except to say
I've heard this issue with it before.

Do you by any chance remember another disc that showed the problem? As far as I can tell, this is the only time I've been bit by it.

The best advice I can give is to try DVD Audio Extractor. It has a 30 day free
trial and a lifetime license with unlimited upgrades is under $40. It is the software
that most others I'm aware of use for this.
https://www.dvdae.com/
Thanks for the suggestion! I was going to do just that, then suddenly remembered that I have Music Media Helper but haven't really used it much. Turns out that it not only created the 24 bit files I expected but did so much faster than AudioMuxer. I may have just found a new workflow!
 
I just recently found out the hard way--after screwing up a bunch of albums--that using ffmpeg to concatenate multiple 24 bit files into a single one results in the output file being 16 bit. In fact, it was while researching how many I'd ruined that I discovered this issue with the Parsons disc.

I'm still furious about ffmpeg--I had started using it to get used to it in case SoX, which hasn't been updated in years--goes away. If you tell SoX to concatenate, the output is the same as the input (because why on earth wouldn't it be?), but ffmpeg does its own thing.

I mention it because a lot of the Linux audio processing code seems to be shared and copied amongst different applications (e.g., you can tell ffmpeg to resample using SoX's resampling library), so I suspect you're onto something. Still, it's odd that this is the only disc any of us have encountered that shows this issue.
... and thanks to your post, I've realised I replied to the wrong thread. The issue in my post 482 above relates to Ammonia Avenue. Duh! Time for some caffeine methinks.
 
I posted on this back on Page 7 of this thread and after a yap with a couple of other QQ members, have come to the conclusion that they're actually 16-bit with 8-bits of zero-value bloat. I can't hear any difference between them when spinning the BD or the HDD.
That's certainly possible, but I'm having trouble believing that AudioMuxer would perform some kind of analysis on the audio and create different output files than the input based on that analysis. Not only that, but doing so silently seems extra-odd.

I've been wondering if there's some issue with the file headers (or whatever the appropriate term is), but then I wonder why AudioMuxer would be the only thing to pick up on the hypothetical error.

It's all just weird!
 
... and thanks to your post, I've realised I replied to the wrong thread. The issue in my post 482 above relates to Ammonia Avenue. Duh! Time for some caffeine methinks.
Yeah, I'm afraid I/we sorta derailed this thread. I posted here because it's what came up when I searched for the 16 bit problem.
 
That's certainly possible, but I'm having trouble believing that AudioMuxer would perform some kind of analysis on the audio and create different output files than the input based on that analysis. Not only that, but doing so silently seems extra-odd.

I've been wondering if there's some issue with the file headers (or whatever the appropriate term is), but then I wonder why AudioMuxer would be the only thing to pick up on the hypothetical error.

It's all just weird!
Yes, I'm guessing that AudioMuxer looks at what's actually there rather than what the bit depth says that it is. For example, if a 16-bit file has an additional 8-bits of zero-value bloat, AudioMuxer might ignore anything that's zero in the MKV and just spit out what's actually there in the FLAC. I'm only guessing though and have made enough mistookins in this thread already so I think I'll just hush-up!
 
Back
Top