why MP2 files are decoded as s16?

[FranceBB]

Originally Posted by tebasuna51

In audio there are some input classes:

- lossy formats (MP3, AC3, DTS, AAC,... ). The decoders always output float samples, if aren't requested to downsample the output.

True. I always noticed that AAC, AC3 etc output float, but there's something I wasn't sure about and you're the right person to ask since we're here: is there any particular reason why MP2 files are instead decoded as s16? I'm just wondering 'cause I'm curious. Is it because we expect them not to be "good enough" and just of poor quality so that it would be a waste to decode them as float and are therefore decoded as s16? Don't get me wrong, I'm perfectly fine with the decoding the way it is today, but I'm curious.

[tebasuna51]

Originally Posted by FranceBB

... is there any particular reason why MP2 files are instead decoded as s16?

I don't know for what but you are right.
By default command line decoders like lame and ffmpeg output s16 int, of course ffmpeg can be forced to output float with -acodec pcm_f32le.

AviSynth decoders ffms2.dll and LSMASHSource.dll also output s16 int without a way to override the downsample.

Only NicAudio.dll output float samples, and like responsible of last versions I can assure you than the internal decoder output is float, and any other format is a posterior downsample.

[qyot27]

Originally Posted by FranceBB

True. I always noticed that AAC, AC3 etc output float, but there's something I wasn't sure about and you're the right person to ask since we're here: is there any particular reason why MP2 files are instead decoded as s16? I'm just wondering 'cause I'm curious. Is it because we expect them not to be "good enough" and just of poor quality so that it would be a waste to decode them as float and are therefore decoded as s16? Don't get me wrong, I'm perfectly fine with the decoding the way it is today, but I'm curious.

If it's ACM you're talking about, take that up with Microsoft or the filter creator.

If you're asking about FFmpeg-based source filters, it's because FFmpeg chooses the fixed-point decoder for both MP1 and MP2 by default, even though they have floating-point decoders as alternates (and despite statements that float decoders are preferred when available, so obviously that doesn't apply in every case, or MP1 and MP2 are just so rarely used that no one really cares; as that commit shows, MP3 was switched to preferring the mp3float decoder three years ago, and AAC and AC3 have their fixed point decoders as the alternates, indicating that the float decoders were the first ones merged in).

 DEAIL. aac                  AAC (Advanced Audio Coding) (decoders: aac aac_fixed ) (encoders: aac aac_mf )
 DEAIL. ac3                  ATSC A/52A (AC-3) (decoders: ac3 ac3_fixed ) (encoders: ac3 ac3_fixed ac3_mf )
 D.AIL. mp1                  MP1 (MPEG audio layer 1) (decoders: mp1 mp1float )
 DEAIL. mp2                  MP2 (MPEG audio layer 2) (decoders: mp2 mp2float ) (encoders: mp2 mp2fixed libtwolame )
 DEAIL. mp3                  MP3 (MPEG audio layer 3) (decoders: mp3float mp3 ) (encoders: libmp3lame libshine mp3_mf )
 D.AIL. mp3adu               ADU (Application Data Unit) MP3 (MPEG audio layer 3) (decoders: mp3adufloat mp3adu )
 D.AIL. mp3on4               MP3onMP4 (decoders: mp3on4float mp3on4 )

FFMS2 doesn't allow you to switch decoders on the fly, and I'm not exactly sure *what* LSMASHSource's 'decoder' parameter is supposed to do, because you can tell it to use decoder X, but the output won't change. My guess is that it's more specifically targeted at the HW/non-HW video codecs than generic formats with multiple different decoders, but I haven't really delved into it.

However, the use of the float decoders can be forced when configuring the FFmpeg libraries that FFMS2 (and presumably LSMASHSource) get linked to.

[tebasuna51]

Originally Posted by qyot27

...
FFMS2 doesn't allow you to switch decoders on the fly, and I'm not exactly sure *what* LSMASHSource's 'decoder' parameter is supposed to do, because you can tell it to use decoder X, but the output won't change...

With this avs:

LWLibavAudioSource("C:\tmp\2w200.mp2", stream_index=0,cache=false,decoder= "mp2float")

I obtained (with BeHappy):

Starting job 2w200_001.avs -> 2w200_001.wav
Found Audio Stream
Channels=2, BitsPerSample=32 float, SampleRate=48000Hz
Writing RIFF header to encoder's StdIn
Writing PCM data to encoder's StdIn
Done

[qyot27]

It would appear that L-SMASH-Works' indexing is not independent of the decoder= parameter. You have to re-create the index if you change the decoder, assuming the default behavior of letting it create an index cache. This doesn't seem to be documented in the README, either.

I would have expected any index would only really document the file structure itself, rather than have the decoder and output format embedded in it. Because this can lead to some unexpected results, like if the index is made with the decoder as mp2float, and then the decoder= parameter is removed from the script, the index isn't recreated and the output is still float. Same the other way: if the index is created without specifying decoder, it outputs s16, and then adding decoder= won't regenerate the index, and the output is still s16.

Yeah, that is how L-SMASH behaves. It rebuilds the index when the user changes the arguments supplied to certain parameters. Before I realized this, I thought that the index files were somehow becoming corrupt.

Originally Posted by qyot27

or MP1 and MP2 are just so rarely used that no one really cares

That was my first thought when FranceBB noticed that decoding is s16 for mp2. Most of the mp2 tracks that I've come across have been present alongside alternatives, such as AC-3, so I've used that instead.

[FranceBB]

Originally Posted by qyot27

If you're asking about FFmpeg-based source filters, it's because FFmpeg chooses the fixed-point decoder for both MP1 and MP2 by default, even though they have floating-point decoders as alternates

I see... so they're there but they're not used by default, unlike AAC, AC3 etc... However you can use the float decoding if you specify it. Got it.

Originally Posted by Richard1485

That was my first thought when FranceBB noticed that decoding is s16 for mp2. Most of the mp2 tracks that I've come across have been present alongside alternatives, such as AC-3, so I've used that instead.

Yep, they're generally carried in .ts files that are broadcasted as CH.3-4.
Generally it's something like:

CH.1-2 AC3 5.1 384 kbit/s 48'000Hz
CH.3-4 MP2 2.0 192 kbit/s 48'000Hz

where the first is offered and the second one is just there for compatibility reasons.
Very often, though, boxes are capable of downmixing the original 5.1 track to 2.0 stereo anyway, so the second track is very rarely used.
Still, even though it's really not a big deal for me to have the decoding as s16 by default unless specified differently, the only reason why I brought it up was that it was indeed "unusual", that's all.

Originally Posted by FranceBB

Generally it's something like:
CH.1-2 AC3 5.1 384 kbit/s 48'000Hz
CH.3-4 MP2 2.0 192 kbit/s 48'000Hz
where the first is offered and the second one is just there for compatibility reasons.

That's pretty much the sort of file that's crossed my path. Grabbing the AC-3 is easier, so that's what probably what most of us do, leaving little interest in how the mp2 decodes.

Originally Posted by FranceBB

Still, even though it's really not a big deal for me to have the decoding as s16 by default unless specified differently, the only reason why I brought it up was that it was indeed "unusual", that's all.

Oh, I realized that, and it's great that you brought it up. It's had the side effect of making me think about audio decoding a bit more, including how I use L-SMASH. It's easy to fall into the habit of assuming that AviSynth(+)/whatever does what you'd expect as a matter of course.