mpg123-users — Mailing list for users of mpg123

Re: [mpg123-users] Security update mpg123 1.32.8: Frankenstein's Monster

[Martin G. <mar...@gm...>]

On 26/10/24 17:38, Thomas Orgis wrote:

> If you do work with stream dumps, usage of MPG123_NO_FRANKENSTEIN or
> the --no-frankenstein option to the mpg123 application is a workaround
> to avoid the formerly dangerous situation in earlier mpg123 releases.


Does this affect apps that use mpg123_open_feed() and, if so, that call 
seems not to have an "options" parameter, so what would I use to set 
NO_FRANKENSTEIN for that handle? I've searched the docs for half an hour 
but haven't found it yet.


Thanks Tom, always on the ball


    M

[mpg123-users] 1.26 and 13.1 backports (Re: Security update mpg123 1.32.8: Frankenstein's Monster)

[Thomas O. <tho...@or...>]

Am Sat, 26 Oct 2024 17:38:40 +0200
schrieb Thomas Orgis <tho...@or...>: 

> I hereby announce mpg123 version 1.32.8. Get it at the usual places.
> Now.

Observing that versions 1.26.x and 1.31.x are still in the wild
(meaning: Debian stable), I ported the recent security fix to those
release series. Please see recent commits to

	svn://scm.orgis.org/mpg123/branches/1.26-fixes and
	svn://scm.orgis.org/mpg123/branches/1.31-fixes

Current code is also visible under

	https://scm.orgis.org/mpg123/branches/1.26-fixes/ and
	https://scm.orgis.org/mpg123/branches/1.31-fixes/


Alrighty then,

Thomas

[mpg123-users] Security update mpg123 1.32.8: Frankenstein's Monster

[Thomas O. <tho...@or...>]

Dear mpg123 folks,

I hereby announce mpg123 version 1.32.8. Get it at the usual places.
Now.

This is an important security update! There is possible buffer overflow
(writing of decoded PCM samples beyond allocated output buffer) for
streams that change output properties together with certain usage of
libmpg123. This needed seeking around in the stream (including scanning
it before actual decoding) to trigger. So, your usual web radio stream
as obvious attack vector is unlikely, as you won't seek around in it.
If you do work with stream dumps, usage of MPG123_NO_FRANKENSTEIN or
the --no-frankenstein option to the mpg123 application is a workaround
to avoid the formerly dangerous situation in earlier mpg123 releases.
This also means that mpg123 will not decode streams of concatenated
files with either varying format or leading Info frames past the first
track anymore.

With this release, the parser has been improved not to store certain
stream properties before actual MPEG frame data matching that property
has been stored. This avoids the inconsistency that triggered the
overflow. Also note that if you always use a fixed decoding buffer for
full stereo of the maximum of 1152 samples per frame, times two and
your choice of encoding, your application is also not susceptible.

Exploitation of this is not trivial, but I cannot rule out the
possibility of gaining code execution. Your exploit payload needs to
pass through an MPEG decoder and PCM synth before possibly reaching the
CPU. Some heap corruption can follow at the least. So update or
mitigate. If you run 1.32.x, there is no excuse not to get the the
latest bugfix release now. 

Basically any version of mpg123 is affected by this, at least those
that explicitly support so-called Frankenstein streams.

Thanks to kkkkk123 for bringing this heir to the initial bug 322 to my
attention.

1.32.8
------
- libmpg123:
-- Add sections to assembly to support PAC/BTI code
   for aarch64 (-mbranch-protection variants), thanks to Bill Roberts
   (github PR 15).
-- Prevent premature application of header info into decoding structure,
   at worst having triggered out-of-bounds writes of decoded PCM data
   (bug 322, again).
- out123: Show --quiet in --longhelp.


Alrighty then,

Thomas

[mpg123-users] releasing mpg123 1.32.7

[Thomas O. <tho...@or...>]

Hi there,

mpg123 1.32.7 is coming out, with only some minor hygiene:

1.32.7
------
- ports/cmake: Work around bug in CMake that does not detect FPU on
  Apple ARM CPUs (github PR 14).
- Fix some laziness (func() to func(void)) for standards conformance.

You can get it from https://mpg123.org/download.shtml as usual.


Alrighty then,

Thomas

Re: [mpg123-users] Trying to understand MPG123_NEW_FORMAT

[Martin G. <mar...@gm...>]

On 7/3/24 22:01, Thomas Orgis wrote:
> Am Wed, 3 Jul 2024 21:01:19 +0200 schrieb Martin Guy <mar...@gm...>:
>> My question is whether the new format applies to the data returned by
>> the call that returned NEW_FORMAT, or whether the new format applies to
>> data returned by the successive calls to mpg123_read (i.e. are the 24576
>> bytes mono data, or the 1536 bytes?)
 >
> MPG123_NEW_FORMAT=-11,	/**< Message: Output format will be
> different on next call.

Many thanks. How did I miss that, it's in the web docs for 
MPG123_NEW_FORMAT. Now it ploughs through the rough terrain without 
stopping and, mapping the mono blip to stereo, makes a slightly 
different burp. It has also fixed two other MP3 files that died half way 
through, so it's not a lone case.

I can only suggest that in the "Returns" section for mpg123_read() to 
list MPG123_NEW_FORMAT as a possible return value with a link to its 
description, if that's possible. It's not important (the info is there 
if you look in the right place) but it might help anyone as stupid as me 
to find it instead of making noise here. :)

Seriously though, thanks again. mpg123 rocks.

      M

Re: [mpg123-users] Trying to understand MPG123_NEW_FORMAT

[Thomas O. <tho...@or...>]

Am Wed, 3 Jul 2024 21:01:19 +0200
schrieb Martin Guy <mar...@gm...>: 

> mpg123_read(16384 bytes) returns MPG123_NEW_FORMAT with 1536 bytes
>     and mpg123_getformat() says it has 2 channels

Looks like some garbage in between leads mpg132 to recognize two frames
of MPEG layer 1 data (384 16 bit samples per frame, amounting to 2*384*2=1536
bytes) and then the stereo MPEG layer 3 stream continues, with some
hickup.

> My question is whether the new format applies to the data returned by 
> the call that returned NEW_FORMAT, or whether the new format applies to 
> data returned by the successive calls to mpg123_read (i.e. are the 24576 
> bytes mono data, or the 1536 bytes?)

Let's see what I wrote back then …

	http://scm.orgis.org/mpg123/trunk/src/include/mpg123.h

 * Decoding/seek functions may also return message codes MPG123_DONE,
 * MPG123_NEW_FORMAT and MPG123_NEED_MORE (all negative, see below on how to
 * react). Note that calls to those can be nested, so generally watch out
 * for these codes after initial handle setup.
 * Especially any function that needs information about the current stream
 * to work will try to at least parse the beginning if that did not happen
 * yet.

MPG123_NEW_FORMAT=-11,	/**< Message: Output format will be
different on next call. Note that some libmpg123 versions between 1.4.3
and 1.8.0 insist on you calling mpg123_getformat() after getting this
message code. Newer verisons behave like advertised: You have the
chance to call mpg123_getformat(), but you can also just continue
decoding and get your data. */


Quote: Message: Output format will be different on next call.

I hoped to make it clear that the new format applies to the data you
get with subsequend read calls. That is why you can get zero bytes
returned with that message, where the new data is withheld. Did you
miss that bit of information among the other text, drowning out the
main point?


Alrighty then,

Thomas

[mpg123-users] Trying to understand MPG123_NEW_FORMAT

[Martin G. <mar...@gm...>]

Greetings

I am trying to do the best I can when reading of a half-broken MP3 file 
where mpg123_read() returns MPG123_NEW_FORMAT three times, and each 
time, I ask mpg123_getformat() what the new format is.
The first time it says the stream now has one channel, then it happens 
again and getformat() says it has 2 channels again.

Specifically, I'm asking for 10240 frames of pairs of shorts and on 
shorter reads the code retries until it has the required block of data:

mpg123_read(40960 bytes) returns MPG123_OK with 40960 bytes written
mpg123_read(40960 bytes) returns MPG123_NEW_FORMAT with 24576 bytes
    and mpg123_getformat() says it has 1 channel
mpg123_read(16384 bytes) returns MPG123_NEW_FORMAT with 1536 bytes
    and mpg123_getformat() says it has 2 channels
mpg123_read(14848 bytes) returns MPG123_OK with 14848 bytes
mpg123_read(40960 bytes) returns MPG123_NEW_FORMAT with 0 bytes,
    still saying it has 2 channels
mpg123_read(40960 bytes) returns MPG123_OK with 40960 bytes
    and from there it carries on working normally

My question is whether the new format applies to the data returned by 
the call that returned NEW_FORMAT, or whether the new format applies to 
data returned by the successive calls to mpg123_read (i.e. are the 24576 
bytes mono data, or the 1536 bytes?)

I've read the documentation many times, but can't figure out whether 
MPG123_NEW_FORMAT's format is retrospective or futuristic.
Any clues would be welcome.

     M

[mpg123-users] mpg123 1.32.6 released (just a build system tweak for better LFS migration on Debian)

[Thomas O. <tho...@or...>]

Dear mpg123 folks,

a little build system tweak arrives in the current mpg123 release.

1.32.6
------
- build: Detect forced 64 bit offsets on a dual-mode system that used
  to default to 32 bits and drop ambiguous suffix-less symbols in that
  case. This avoids subtle ABI breakage (causing memory corruption)
  with existing binaries and instead has them fail during runtime linking.
  You trigger that when having -D_FILE_OFFSET_BITS=64 in your compiler
  flags during mpg123 build.


If this does not mean anything to you … you might just ignore it. No
new features, just less symbols in a library built in an environment
with enforced large file support.



Alrighty then,

Thomas

[mpg123-users] releasing mpg123 1.32.5

[Thomas O. <tho...@or...>]

Hi folks,

some cleanup comes to you with mpg123 version 1.32.5:

1.32.5
------

- build:
-- CMake port uses CFLAGS for pulse/jack/tinyalsa properly now (bug 366).
-- CMake port links libsyn123 with libm now (bug 370).
- libmpg123:
-- Fix --enable-portable (no usage of LFS_WRAP_NONE, bug 368).
-- Fix dct36 wrapper usage for x86-64 and NEON. Stupid (bug 367) and
   also avoid returning void.
-- Make ARM builds work with nagging (missing feature macros for std=c99).


Grab it if you so desire from

	https://sourceforge.net/projects/mpg123/files/
or
	https://mpg123.org/download.shtml

and have a good time.


Alrighty then,

Thomas

[mpg123-users] mpg123 1.32.4 released

[Thomas O. <tho...@or...>]

Hi all,

some internal rearrangements and build system enhancements come with
mpg123 1.32.4:

1.32.4
------
- build:
-- Reorganize shared headers, API headers into src/include.
-- Use relative include paths, avoiding internal directories in
   CPPFLAGS except for config.h.
-- Group C99 feature checks and make several standard headers
   mandatory.
-- Get rid of SIZE_P, OFF_P and friends.
-- Only enforce dummy module together with libout123, to be able
   to build individual modules using --disable-components logic.
- out123:
-- added --libversion
- libmpg123:
-- Avoid indirect branches into the assembly routines by using C wrappers
   also for dct36, relieving us of the need to care for bti / endbr
   instructions for control flow integrity.


Get it from the usual places …


Alrighty then,

Thomas

Re: [mpg123-users] libmpg123 opens non-mp3 files

[Martin G. <mar...@gm...>]

Il giorno gio, 21/12/2023 alle 07.16 +0100, Thomas Orgis ha scritto:
> Wait, you have mp2 files that mpg123 can play fine, but libmpg123
> does not?
> 
> I'd like to see an example of that.
> 
> Also: If you have issues with libsndfile's mp3 decoding, I hope you
> can provide test cases and reports to fix that ...



While extracting minimal code to make a test program I spotted a logic
error left over from the days when I used to sniff filename extensions
to choose the decoder. Yes, it does decode those mp2's perfectly.

Making a test case for libsndfile's decoding could be harder as I have
to pan back and forth vigorously to make it happen. If I can isolate it
I'll forward it to them.

Thanks for the input - another bug bites the dust

Blessings

    M

Re: [mpg123-users] libmpg123 opens non-mp3 files

[Martin G. <mar...@gm...>]

Il giorno gio, 21/12/2023 alle 07.16 +0100, Thomas Orgis ha scritto:
> Wait, you have mp2 files that mpg123 can play fine, but libmpg123
> does not?
I only have two mp2 files (from long ago...), both visible under
martinwguy.net/mp2
Both play fine with mpg123 and libsndfile so I guess I must be doing
something wrong.

Blessings

    M

Re: [mpg123-users] libmpg123 opens non-mp3 files

[Thomas O. <tho...@or...>]

Wait, you have mp2 files that mpg123 can play fine, but libmpg123 does not?

I'd like to see an example of that.

Also: If you have issues with libsndfile's mp3 decoding, I hope you can provide test cases and reports to fix that ...


Alrighty then,

Thomas Orgis

Re: [mpg123-users] libmpg123 opens non-mp3 files

[Martin G. <mar...@gm...>]

Il giorno mer, 20/12/2023 alle 13.50 +0100, Thomas Orgis ha scritto:
> Libmpg123 tries as hard as it can to extract something out of the
> data you give it.
Understand

> libmagic [...] is a good way to pre-filter files.
Good call! I've put this in and it has resolved decoding all the bogus
audio files, except for MP2's which libmpg123 "succeeds" in opening but
returns me the correct length of total silence. Strangely enough,
libsndfile does succeed in opening and in returning valid data, and the
"mpg123" command plays them fine so i guess I must be doing something
wrong. For my upcoming release, I'm currently checking for .mp2 on the
end of the filename and just give them to libsndfile instead. Gak!

> Oh, you can also just use libsndfile
I prefer libmpg123 for its maturity, ubiquity, reliability, perfect
sample-accurate seeking and tolerance of funny files.
As regards libsndfile's MP3 support (finally!),  it will take a few
years for it to arrive in all the distros, and "normal" people, once
they have a working system, tend not to chase the latest releases as
long as their box works.
I've tried the new libsndfile mp3 support (whose coding by FFitch I
followed avidly) but it doesn't work reliably in my app when you make
it seek a lot, and it returns garbage noise, probably due to the
freshness of the code.

Which just leaves me wondering why, if the libsndfile MP3 support
relies on mpg123, its seeking isn't as good and why libmpg123 appears
to be handing me silence for them.

Many thanks for the suggestions. Onward!

   M

Re: [mpg123-users] libmpg123 opens non-mp3 files

[Thomas O. <tho...@or...>]

Am Tue, 19 Dec 2023 22:58:06 +0100
schrieb Guido Jäkel via mpg123-users <mpg...@li...>: 

> I would like to suggest to use the 'file' command to detect the MIME
> type of the audio files first.

Libmpg123 tries as hard as it can to extract something out of the data
you give it. This includes all kinds of weird historically used formats
including MPEG data with a leading RIFF header suggesting it's a WAV
file. This might confuse the 'file' tool, too.

But for regular files that don't try to be funny, where a header for WAV
or OGG Vorbis really means that, file, or, respectively, libmagic when
used in your own program, is a good way to pre-filter files.

MPEG audio is a bit special in that it doesn't specify a container
format with clear identification. It's a stream of raw frames and
metadata got tacked on later.

So maybe it's more sensible to check if it is something else known
first, as OGG etal. are easily identified, and only after that throw
libmpg123 on it.

Oh, you can also just use libsndfile for all your audio reading, as
current libsndfile has MP3 read and write support via libmpg123 and
liblame. Libmpg123 is for folks who really want to deal with MPEG layer
3 files, possibly including some specifics (like high-efficiency volume
scaling or the crude equalizer).


Alrighty then,

Thomas

Re: [mpg123-users] libmpg123 opens non-mp3 files

[Guido J. <Gui...@GM...>]

Dear Martin,

I would like to suggest to use the 'file' command to detect the MIME type of the audio files first.

E.g.

	$ file -bi Renzo\ Arbore\ \&\ Lino\ Banfi\ -\ E\ La\ Candela\ Va\ \(1990\).wav
	audio/x-wav; charset=binary


Guido

On 19.12.23 20:40, Martin Guy wrote:
> Hi!
>     I'm writing a soundfile visualization program that tries to open
> audio files first with libmpg123 then, is it fails, with libsndfile
> then, if that fails, with libav but I'm finding that libmpg123
> "succeeds" in opening some files, wav and ogg, but the returns the file
> length as 0.048 seconds but fails to return any meaningful audio data.
>     I'm doing mpg123_open() and mpg123_getformat() and, if either fail,
> falling back to the other libs. That was enough for one wav which it
> thought it could open but failed to get the format for, but foranother
> two both succeed, giving me garbage.
>     Is this expected behaviour, and is there anything I can do better to
> detect that it's not an mp3 file?
>     In case it's useful, the audio files in question are visible under
> martinwguy.net/test where "Renzo Arbore..." is the one where open()
> succeeds but get_format() fails, but with the other two both succeed.
>
> Thanks!
>
>      M
>
>
>
> _______________________________________________
> mpg123-users mailing list
> mpg...@li...
> https://lists.sourceforge.net/lists/listinfo/mpg123-users

[mpg123-users] libmpg123 opens non-mp3 files

[Martin G. <mar...@gm...>]

Hi!
   I'm writing a soundfile visualization program that tries to open
audio files first with libmpg123 then, is it fails, with libsndfile
then, if that fails, with libav but I'm finding that libmpg123
"succeeds" in opening some files, wav and ogg, but the returns the file
length as 0.048 seconds but fails to return any meaningful audio data.
   I'm doing mpg123_open() and mpg123_getformat() and, if either fail,
falling back to the other libs. That was enough for one wav which it
thought it could open but failed to get the format for, but foranother
two both succeed, giving me garbage.
   Is this expected behaviour, and is there anything I can do better to
detect that it's not an mp3 file?
   In case it's useful, the audio files in question are visible under
martinwguy.net/test where "Renzo Arbore..." is the one where open()
succeeds but get_format() fails, but with the other two both succeed.

Thanks!

    M

[mpg123-users] mpg123 1.32.3 released

[Thomas O. <tho...@or...>]

The (up to now) final release of the quick regression fix succession of
the 1.32.x series is out. It's a rough ride, but we're getting there.

Maybe we've even arrived.

1.32.3
------
- ports/cmake: Only enable modules with GetThreadErrorMode() on Windows.
- compat: Define EOVERFLOW for ancient Windows toolchains.
- libmpg123, libsyn123: always ifdef LFS_LARGEFILE_64 (not just if)
- libsyn123: re-introduce _32 wrappers in addition to suffix-less ones
  (regression from 1.31, bug 363)


Alrighty then,

Thomas

[mpg123-users] mpg123 1.32.2 released with build fixes for ABI regression from 1.31

[Thomas O. <tho...@or...>]

Hi all,

please upgrade to mpg123 1.32.2 which yet again fixes things that I
broke with 1.32.0. The CI and pre-release testing that we have is
covering only part of what we got out there. Now we missed the case of
-D_FILE_OFFSET_BITS=64 on 64 bit platforms, where the _64 symbols were
missing.

Also, the CMake build got some important fixes to complete what 1.32.0
should have had.

Pleae just upgrade, for these fixes:

1.32.2
------

- libmpg123: Re-introduce _64 symbols on native 64 bit offset platforms. This
  was a regression since 1.31 series. Sorry, too much cleanup, not enough
  testing.
- build:
-- Better O_LARGEFILE logic, avoiding redefintion.
- ports/cmake:
-- Require C99 (bug 360, among other points, thanks to Ozkan Sezer).
-- Fix broken O_LARGEFILE logic (bug 360).
-- Typo fix and cleanup, also manual SSE switch for Android on old x86 (bug 359).


Alrighty then,

Thomas

[mpg123-users] mpg123 1.32.1 with build fixes

[Thomas O. <tho...@or...>]

There were some things amiss with the build system changes in the last
release, most notably the man pages went missing. Further fixes mainly
for the CMake build are also still in the works. Sorry for the fuss, but
only the announced release got the testing we'd like to have had beforehand.

1.32.1
------
- Include man pages again in tarball and install. We cannot avoid the empty
  man directory when disabling programs with autoconf.
- Fix signal handler prototype, avoiding some justified warnings.
- ports/cmake:
-- Include CheckTypeSize, which seems to be needed sometimes (bug 357).
-- Avoid O_LARGEFILE redefinition, logic closer to autoconf.


Alrighty then,

Thomas

[mpg123-users] mpg123 .1.32.0 released

[Thomas O. <tho...@or...>]

Dear people who at least know what mpg123 is,

version 1.32.0 got just released. Major points are the introduction of
yet another API set to yet again fix the largefile support situation,
where you can rely on fixed 64 bit integers instead of touching off_t,
and fixing of the meaning of the offset for mpg123_seek() when working
from the end.

But there is more … please see the full list:

1.32.0
------
- build:
-- Move version handling out of configure.ac to ease other build systems.
-- Include "fmt123.h" instead of <fmt123.h> in main API headers to make it more likely the
   correct one is included (at least gcc picks the one in the same directory as the
   including header first).
-- All headers are build-independent now.
-- Fix build for picky linkers by avoiding definition of wrap_getcpuflags() where it is not
   used (spurious linker error to non-exitent getcpuflags(), bug 353).
-- Handle deprecation of C99 detection macro in autoconf 2.70.
-- No use of AC_SYS_LARGEFILE anymore for explicit handling and differing choice for
   the libraries and frontend programs.
-- Added --enable-portable and --disable-largefile to configure, removing the other
   largefile-related options.
-- Added --disable-components --enable-libmpg123 to only build libmpg123 (and likewise
   --enable-libout123, --enable-libout123-modules, --enable-libsyn123) to autoconf
   build. CMake build has something  similar with BUILD_PROGRAMS and BUILD_LIBOUT123,
   which leave only libmpg123 and libsyn123 if disabled). (bug 351)
-- Consistent formatting of ./configure --help with AS_HELP_STRING().
- ports/Sony_PSP: removed
- mpg123:
-- Added --libversion.
-- Added proper A-B looping with terminal control key 'o', renamed
   --pauseloop to --presetloop.
-- Really get rid of mpg123_position() usage. (It was all lies before!)
-- Fix terminal progress info when seeking in stopped mode (1.31 regression).
-- Patch up interaction of output buffer with generic remote control, adding
   non-interruptible drain after P 3, and dropping buffer on QUIT.
-- Uppercase some generic control replies for consinstency: SILENCE, PROGRESS,
   MUTE, UNMUTE
- libmpg123, libout123, libsyn123:
-- Bumped API version for version query functions.
-- Replaced nearly all symbol renames with explicit INT123_ prefix declarations
   (intsym.h close to empty now).
- libout123:
-- Add sleep builtin output module (silent, but proper timing).
- libsyn123:
-- Introduced SYN123_PORTABLE_API for an API without off_t and ssize_t
   (see NEWS.libsyn123).
- libmpg123:
-- Internal I/O using explicit largefile support via off64_t, lseek64, fallback
   to plain 32 bit off_t.
-- Added explicit 64 bit API with 64 suffix (mpg123_tell64(), not mpg123_tell_64()).
   This allows full avoidance of ambiguus off_t. The API is always using 64 bit
   integers, regardless of internal implementation. (bug 344)
-- Introduced MPG123_PORTABLE_API for an API subset without off_t and
   ssize_t.
-- Made mpg123_seek() and friends ignore offset sign for SEEK_END (always seeking
   towards beginning, assuming negative offset) to make lseek()-conforming usage
   possible. Seeking beyond the end never made sense, so no loss of valid functionality.
- Overall use of INT123_strerror(), trying to use thread-safe strerror_l() if possible.


Please get it from

	https://sourceforge.net/projects/mpg123/files/mpg123/1.32.0
or
	http://mpg123.org/download.shtml
.


Alrighty then,

Thomas

[mpg123-users] mpg123 1.31.3 released (with security fix)

[Thomas O. <tho...@or...>]

Dear folks,

there is a new bugfix release of mpg123 out:

1.31.3
------
- build:
-- Fix --disable-8bit.
-- Fall back to generic decoder if no yasm for MSVC (bug 346).
-- Fix some pedantic compiler warnings, avoid breaking libtool wrappers.
- mpg123:
-- Fix verbose position printout for new resampling outside libmpg123 (where
   output rate differs from decoding rate).
- libsyn123:
-- Fix reconfiguration of resampler to avoid double free when reducing
   decimator stages to zero (bug 350). Thanks to Youngseok Choi for reporting
   this fuzzed issue.

The last one is triggered in mpg123 you enable resampling to a low
sampling rate and have input that switches around input sampling rate
on the fly, reducing the number of necessary decimator stages to zero.
There is the same memory location freed two times in quick succession
(without explicit allocations in between) and the decoding ends due to
the failure to adapt the resampler.

The corrected version adapts the resampler state to properly switch
between down- and upsampling, even.

Libmpg123 itself is not affected at all, just direct libsyn123 usage or
the mpg123 binary.


Alrighty then,

Thomas

Re: [mpg123-users] Downmix MP3 to mono and play on one channel only

[Thomas O. <tho...@or...>]

For the list: not -S, but -s, or more clearly, --stdout.


mpg123 -e f32 -s -m  left.mp3 | out123 --inputenc f32 --inputch 1 --channels 2 --mix 1,0
mpg123 -e f32 -s -m right.mp3 | out123 --inputenc f32 --inputch 1 --channels 2 --mix 0,1


Alrighty then,

Thomas

Re: [mpg123-users] Downmix MP3 to mono and play on one channel only

[Thomas O. <tho...@or...>]

Am Mon, 13 Mar 2023 21:47:03 +0100
schrieb Bastiaan de Waard via mpg123-users <mpg...@li...>: 

> configure mpg123 to first down-mix the MP3 to mono and then plays
> that sum on a specific channel

Something like that comes to mind:

mpg123 -e f32 -S -m  left.mp3 | out123 --inputenc f32 --inputch 1 --channels 2 --mix 1,0
mpg123 -e f32 -S -m right.mp3 | out123 --inputenc f32 --inputch 1 --channels 2 --mix 0,1

(You could use the default 16 bit encoding, but that would waste time
re-converting samples.)

The out123 tool in recent versions has the --mix parameter for such fun.


Alrighty then,

Thomas

[mpg123-users] Downmix MP3 to mono and play on one channel only

[Bastiaan de W. <bas...@tm...>]

Hi :-)

I have a quick query. I've observed that when I use the command "mpg123 -0 file.mp3" to play a stereo MP3 file, it only decodes the left channel information while still sending it to both channels (L & R) of the audio interface. Is it possible to configure mpg123 to first down-mix the MP3 to mono and then plays that sum on a specific channel (either Left or Right)? We require this functionality for our project as we need to play two different MP3 files on each channel.

Platform: FreeBSD 13

Best regards,
Bastiaan