Menu

#312 Broken Sound of a MP3 file / libmpg123

1.27.x
closed-fixed
nobody
bug (2)
7
2021-06-06
2021-06-03
pama
No

Hello,
I have multiple mp3 files which sound very "odd" played over VLC (using mpg123). The reason I am convinced it's a problem in mpg123 is, that it works actually in every other Codec/Software (even windows media player! :D). I put two example files in this Ticket.

I also put this "bug" in private mode since I am unsure of copyright issues when I post that publicly.

Discussion

1 2 > >> (Page 1 of 2)
  • Thomas Orgis

    Thomas Orgis - 2021-06-03

    This needs more information. I do not see an issue with the files. What's your platform? Where is your build of vlc and libmpg123 coming from?

    Can you test the mpg123 stand-alone program to rule out mishaps on the vlc side?

     
  • pama

    pama - 2021-06-03

    Hey,
    I too thought at first it's a problem with vlc. But three of their Maintainers told me, that it would be a problem with libmpg123.

    *Thomas Guillem
    Thomas Guillem @tguillem · 8 hours ago
    Maintainer
    "
    Hello, thanks for the report. I can reproduce it on Linux with VLC 4.0 and VLC 3.0, using the mpg123 codec.

    No issues with avcodec.

    As a temporary workaround, you can force the avcodec codec in VLC advanced preferences.
    "*

    And they ended with:

    Rémi Denis-Courmont @Courmisch · 3 hours ago
    Maintainer
    "
    We cannot take this any further. Consider reporting your problem to the mpg123 project.
    "

    I am not a programmer... I really can't tell where exactly the issue is.
    I found something, which is not working properly and thought I can help the community by reporting this. The VLC Maintainers closed the "issue / bug report / ticket" already on their side.

    I can give you more info:
    - tried it on Android and Windows x64.
    - My Build of VLC is the newest stable one.

    "Can you test the mpg123 stand-alone program to rule out mishaps on the vlc side?"
    I never tried mpg123 before. But I will now. That might take some time.

     

    Last edit: pama 2021-06-03
  • Thomas Orgis

    Thomas Orgis - 2021-06-03

    OK, so you are talking about a Windows build. That is important information. "Newest stable build". You mean you downloaded an official binary for Windows?

    I need to check how vlc uses mpg123 and prepare a local build, I guess. I am not working on Windows and there are still some variables, as you can prepare libmpg123 in differing ways. Our windows binaries (https://mpg123.org/download/win64) are prepared in the mingw environment. But you can also build it in MSVC (old days: project file, fresher: CMake build that needed recent fixing).

    I guess VLC uses some build from MSVC, which might have issues to sort out. I also need to look at the API usage. It does not seem to be a decoder issue as such.

     
  • pama

    pama - 2021-06-03

    I downloaded the newest Windows binary of mpg123 (https://mpg123.de/download/win64/1.27.2/mpg123-1.27.2-static-x86-64.zip) and started it with PowerShell. Playing one of these files i send you I sadly have the same issue. (See screenshot, of cause you can't hear it, but its "broken" the same way, believe me).
    -> I have it also on Android (tested it on two devices)

    Something with these files causes problems with mpg123.

    Not sure if the following is helpful anymore... I had that written before testing mpg123 itself:

    Well, I am not an VLC expert either. I am using the Windows x64 Binary. ->Didn't compile it myself.
    Here: https://www.videolan.org/vlc/releases/3.0.13.html they mention "New MPEG-1 & 2 audio layer I, II, III + MPEG 2.5 decoder based on libmpg123"
    Here: https://code.videolan.org/videolan/vlc/-/blob/master/modules/codec/mpg123.c
    That seems to be the VLC Module used.
    And here: https://code.videolan.org/videolan/vlc/-/blob/master/contrib/src/mpg123/rules.mak
    They assign some flags to the libmpg123 -->
    MPG123_CFLAGS += -D_FILE_OFFSET_BITS=64
    and
    MPG123CONF += --with-default-audio=dummy --enable-buffer=no --enable-modules=no --disable-network
    The Code there talks about mpg123 version 1.26.2. The maintainers of VLC tried it with the newest version too. -> "Indeed, same issue using the mpg123 tools and using the latest version: mpg123 1.27.2."

     
  • Thomas Orgis

    Thomas Orgis - 2021-06-03

    My Android build of VLC (3.3.4 from F-Droid) doesn't seem to have mpg123.

    Thanks for the pointers. They use the autotools build with vissual C on Windows? Hm. Also, someone could have given me notice that I ship the generated syn123.h. Ts, ts. Fixed that one.

    That you year distortion also with the plain mpg123 is strange. On Linux, I don't get any issue.

    Also, there are no decoder error messages. It must be something in the synthesis or rather in the passing over of the data. Can you create a little piece of WAV like this?

    mpg123 -n 380 -w out.wav in.mp3
    

    This should create about ten seconds of decoded data in the wav. Does that file sound OK when played?

    I'll see about getting a vlc build …

     
  • pama

    pama - 2021-06-03

    Hey again,
    the (on windows with above mentioned version) created .wav file has the same odd "breaking" sound. But now this file played with other players have that issue too! Very smart... :D now you can hear it too.

    On Android I use the play store version but also 3.3.4 and have these problems too.

     

    Last edit: pama 2021-06-03
  • Thomas Orgis

    Thomas Orgis - 2021-06-03

    Uh. The WAV you attached sounds perfectly fine here. Can you describe what you mean with "breaking" sound? I don't use the Play store on Android … seems like F-Droid needs a bump to switch from libmad in their VLC build, so that I can experience libmpg123 bugs there, too;-)

    But really, let's focus on the experience with out.wav. It sounds just fine here. Also looks normal in Audacity (attached). I have to wonder if it is something strange in your setup, but since you say that you have the same issue under Android, I do not know what to make of that.

    Since VLC folks said they can reproduce … I hope my VLC build brings some light to this (ongoing).

     
  • pama

    pama - 2021-06-03

    Okay, now I really wanted to make sure, that I don't tell lies. With other MPEG Files it works fine.
    But with the mentioned ones and the wav it simply doesn't work. Here what I tested:

    • Windows - 3 machines with different setups all newest version of Windows x64
      -> Here was tried mpg123, VLC, MPV, PotPlayer, Windows Media Player
      (Sidenote: On my laptop its happening too... but it has very bad speakers... there it was almost imperceptible.)

    • Android - 3 devices with different brands each. Also different Versions of Android and Processors.
      -> MPV, VLC

    • Linux - 1 Machine using Garuda Linux (close to Arch Linux) x64
      -> MPV, mpg123, VLC

    All of these had the "broken / Cracking" sound with the wav-file. When I tried the mp3-files just VLC (using libmpg123) and mpg123 had issues.

    To confirm it, I asked a friend to test these files too, and she had the same issues on her devices.
    In addition, as you said the Maintainers of VLC also could reproduce it.

    Never had any troubles with this library (codecs of mpg123), just now with these files.

     

    Last edit: pama 2021-06-03
  • Thomas Orgis

    Thomas Orgis - 2021-06-03

    I got vlc built. I see that it has the mpg123 plugin. I need to figure out where to tell vlc about which codec to use. I don't see a setting for that. You switched to ffmpeg/libav in preferences, right? Where exactly?

    I'll fetch my headphones. Do you mean there is just some distortion added, but the normal sound as such is present?

     
  • pama

    pama - 2021-06-03

    Oh no... I didn't change anything. That was just the "workaround" of the VLC devs. They wanted me to switch to a different library. libmpg123 is the default.

     
  • Thomas Orgis

    Thomas Orgis - 2021-06-03

    Now I get something. It's a stereo/phase thing. My laptop has a mono speaker. With headphones, it is clearly noticeable. Playback with mpg123 --mono reduces it a lot, but it is still apparent. Another simple test with the laptop speaker is just the left channel:

    mpg123 --left test.mp3
    

    Weird stuff. But OK, I can confirm that there is something going on. Actually … re-testing … with the mono speaker it indeed sounds just fine. I am not even sure if it sounds better if playing stereo that is mixed to mono by the hardware than decoding to mono.

    So there is something funky with the joint-stereo coding of these files. Can you give me details on the source/encoder used?

     
  • pama

    pama - 2021-06-03

    Nah... I have them since some time already. I don't know the source anymore.
    A bigger analysis would show:
    Format : MPEG Audio
    Format version : Version 1
    Format profile : Layer 3
    Format settings : Joint stereo / Intensity Stereo + MS Stereo
    Duration : 10 min 39 s
    Bit rate mode : Constant
    Bit rate : 96.0 kb/s
    Channel(s) : 2 channels
    Sampling rate : 44.1 kHz
    Frame rate : 38.281 FPS (1152 SPF)
    Compression mode : Lossy
    Stream size : 7.32 MiB (100%)

    The key might probably be the "Joint stereo / Intensity Stereo + MS Stereo"?

    Btw... I can (almost) fix it in VLC with putting "effects" on and then max the "dry". haha

     

    Last edit: pama 2021-06-03
  • Thomas Orgis

    Thomas Orgis - 2021-06-03

    It's intensity stereo, a rare variation that there isn't even compliance data for. I added some files with the output of an earlier mpg123 itself as reference. A file simiar to yours is

    http://scm.orgis.org/view/mpg123/test/compliance/layer3is/drumshort48kHz.bit

    (just realized that this is the only actual IS file in the folder … the other sample rates didn't really make it … that old l3enc is not to be trusted!). But this one decodes fine. Yours differs in another extended channel mode bit. Maybe there's something bad in that path.

    But really, can you tell me which encoder that is? I had to hunt down an old binary of the original reference encode to even be able to create a sample file that features intensity stereo. It is quite unusual.

     
  • pama

    pama - 2021-06-03

    Uhm... honestly I didn't encode it. The decoding works fine in some libraries. Where they have their info from... that's out of my reach :(.

    The fileinfo I send before comes out of https://potplayer.daum.net. But that is proprietary... (I should feel bad using it, but it works very good.)

    When I use https://mp3guessenc.sourceforge.io it results in "maybe this file is encoded by xing (new)".

     
  • Thomas Orgis

    Thomas Orgis - 2021-06-03

    And what is really weird: The content is a perfect MONO audio stream. When I take the output of ffmpeg and mix the two channels with 0.5,-0.5 I get nice silence. So you got

    1. A weird stereo encoding
    2. of a mono audio stream.

    Another fun fact: When I disable the i-stereo decoding in mpg123, the file sounds normal. There is absolutely no stereo information present. So maybe this is a corner case of libpmg123 where it ventures into strangeland when i-stereo with full-on mono data is requested.

    I need to check what ffmpeg does differently.

     
  • pama

    pama - 2021-06-03

    Yes... I hope I don't waste your time.

    Feeding the file into FFMPEG and let it convert it with standard parameters actually fixes the file.
    -> The output is "Stereo, fltp". I don't know what "fltp" defines.
    -> And also It says the input is "mp3float".
    -> The used encoder is "lavc58.134.100 libmp3lame".

    The resulting file works fine everywhere.
    Let me know if I can help in any way. I will be back tomorrow.

     
  • Thomas Orgis

    Thomas Orgis - 2021-06-03

    Well, ffmpeg and MAD agree on decoding this strange mono file just fine. The current hypothesis is indeed that you found a decoder bug. Quite a feat for a decoder that is around since about 25 years.

    As this is supposed to be a pure mono file, it should be possible to debug this by carefully looking where the channel difference is created. But this might need time. I did not expect having to fix up such a bug in 2021.

    As for effects … mixing to mono also works quite well, but I am not sure how much distortion is artificial and how much is just Stephen's voice;-)

    And yes, the issue is "Joint stereo / Intensity Stereo + MS Stereo"? The Intensity Stereo part is rare in layer III files, as the one encoder that really matters (LAME) does not offer support for creating those files. It only does Joint stereo / MS Stereo.

     
  • Thomas Orgis

    Thomas Orgis - 2021-06-04

    OK, more, as I take this personally: I checked that ancient mpg123-0.59r-thor6 does decode this correctly. So this is a regression that was introduced under my reign over the project. It will be fixed soon.

    Do you think it is OK to extract a little snippet (a second?) of the recording as compliance test file for the future (public in the repo)? I think there are such fair use boundaries in various jurisdictions.

     
  • pama

    pama - 2021-06-04

    Hello,
    I am sorry to put that on you. Nobody noticed and requested such a thing in 25 years. Which speaks for the code quality... since there are some libraries having to fix such stuff every other month.
    So, honestly no big deal. :)

    More I see the issue at xing. When really xing (1999) was used to encode these files... then I don't wonder, that there might be some issues relating to those files today.

    Well, when you want to put it in the repo... that might be tricky. I guess a snipped of 5 - 10 seconds will be fine. I am not a lawyer but when we use it to fix something... In addition... the copyright is from 1998 -> I guess it is okay to use it partially.

     

    Last edit: pama 2021-06-05
  • Thomas Orgis

    Thomas Orgis - 2021-06-04

    The issue was introduced with mpg123 1.25.7, with a fix for potential buffer overflows on bad data. Those fuzzers prompted me to but guards into place … and apparently they are too strict here. part2_3_length==0 does not mean that there is no scalefactor data. It just means that there are no new frame body bits needed … the relation with ssize seems to be key.

    I'll see to fixing that. Good catch, after all.

     
  • Thomas Orgis

    Thomas Orgis - 2021-06-05

    Fixed in 1.28.0 release. You might want to poke VLC folks to update their builds.

     
  • Thomas Orgis

    Thomas Orgis - 2021-06-05
    • status: open --> closed-fixed
     
  • Thomas Orgis

    Thomas Orgis - 2021-06-05
    • Attachments has changed:

    Diff:

    --- old
    +++ new
    @@ -1,2 +1 @@
    -buggy_mp3.mp3 (7.7 MB; audio/mpeg)
     buggy_mp3_2.mp3 (6.0 MB; audio/mpeg)
    
     
  • Thomas Orgis

    Thomas Orgis - 2021-06-05
    • Attachments has changed:

    Diff:

    --- old
    +++ new
    @@ -1 +0,0 @@
    -buggy_mp3_2.mp3 (6.0 MB; audio/mpeg)
    
     
  • Thomas Orgis

    Thomas Orgis - 2021-06-05
    • private: Yes --> No
     
1 2 > >> (Page 1 of 2)

Log in to post a comment.