mpg123 Activity
Brought to you by:
sobukus
Activity for mpg123
-
abdelaziz sbaai posted a comment on ticket #385
Environment - Platform: armv7l (Raspberry Pi, Raspbian Buster/Debian 10) 1. The problem only occurs in remote mode; plain mode works fine Plain mode plays the stream without issue: mpg123 https://jazzradio.ice.infomaniak.ch/jazzradio-high Remote mode crashes: # Terminal 1 mpg123 -R --fifo /tmp/mpg123-fifo.cmd # Terminal 2 echo "LOAD https://jazzradio.ice.infomaniak.ch/jazzradio-high" > /tmp/mpg123-fifo.cmd Output before crash: @I jazzradio-high Segmentation fault. 2. Stream capture replayed with...
-
Thomas Orgis posted a comment on ticket #385
Next step would be to check if a stream capture (--streamdump file) that is then opened with correct --icy-interval from disk also crashes. This isolates things from the actual HTTP process. Of course, the history of the corrupted string struct would be good
-
I cannot reproduce on AMD64. Is this specific to remote control mode or does plain mpg123 https://jazzradio.ice.infomaniak.ch/jazzradio-high also crash? It also prints the ICY info for me … though it is not very informative: src/mpg123 https://jazzradio.ice.infomaniak.ch/jazzradio-high High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3 version 1.33.5-dev; written and copyright by Michael Hipp and others free software (LGPL) without any warranty but with best wishes Directory: https://jazzradio.ice.infomaniak.ch/...
-
Segfault in remote mode when LOADing HTTPS/ICY stream on ARM (Raspberry Pi)
-
Can you test current trunk / snapshot? I followed the original suggestion to copy the aarch64_defs.h approach now. I've seen the sections announcing shadow stack now, but I have not tested this anywhere.
-
Remilia Scarlet posted a comment on ticket #384
Sorry for the late reply! Yeah, keep the whole file if you wish, it's fine with me. I don't think support for every single frame would be necessary if it adds additional symbols to the library. Just ones with substantial use in the wild and strong use cases.
-
Revisiting the ID3v2 spec … there are lots of frames that I never encountered, ideas for specifc uses that did not materialize. As I said, adding text fields should be easy enough, but there is lots of funny binary frames, or things like LINK … I do not think that it is libmpg123's task to provide a full implementation of the standard. It is unfortunate that you got lots of MusicBrainz IDs stored as TXXX frames and only one of them as UFID. I am pondering how to add API for the UFID frames. It needs...
-
Can I keep the leading bits of your file as test data in the mpg123 distro? I guess I'll just add parsing and testing of the dump for the fields it has.
-
Awesome, sounds good.
-
Hm, so id3v2 is not actually displaying the binary data for UFID. I thought I'd let mpg123-id3dump show it in hex. Regarding additional fields: I guess you'd like to see the URL fields (starting with W), too. Then there's TORY. There is a numer that I did not cover. Adding more text-like fields is easy. The binary ID needs some specific bits, but not such a big deal. So far there was no demand for more fields, but sure, I can add more.
-
So I came across this while adding support for MusicBrainz IDs to the music player I wrote, Benben, which uses libmpg123 for MPEG-1 and ID3 support. Support for these IDs was being added because, when you submit to ListenBrainz, adding MusicBrainz IDs (if they exist in the file) help ensure a better match for the user. And it turns out, MusicBrainz Picard uses the UFID frame to store the MusicBrainz Recording ID. I'm not totally sure what other fields aren't getting handled, but I can spend some...
-
So I came across this while adding support for MusicBrainz IDs to the music player I wrote, Benben, which uses libmpg123 for MPEG-1 and ID3 support. Support for these IDs was being added because, when you submit to ListenBrainz, adding MusicBrainz IDs (if they exist in the file) help ensure a better match for the user. And it turns out, MusicBrainz Picard uses the UFID frame to store the MusicBrainz Recording ID. I'm not totally sure what other fields aren't getting handled, but I can spend some...
-
Sure, mpg123's ID3 parsing is not exhaustive. It is mostly about (text) fields useful for player display. Can you give an example file and also show the id3v2 output? Seems like id3v2 doesn't actually create UFID frames. id3v2 --UFID xxx foo.mp3 does not result in anything being added to the file. So I wonder how you populate these and also, since the data is supposed to be unspecific binary, how it is to be displayed. This field seems to be designed for the same purpose that Amazon utilizes a simple...
-
The UFID frame of an ID3v2 tag does not get parsed
-
sunbeachbeforesunset posted a comment on ticket #383
GCC and Clang have a cet.h that you can include that defines the section, eg look at /usr/lib/gcc/x86_64-linux-gnu/13/include/cet.h, you could simply use: #if defined(__has_include) && __has_include(<cet.h>) #include <cet.h> #endif Or, if you don't want an include, you can copy the contents of cet.h into an mpg123 header. Note that cet.h defines support for both SHSTK and IBT, but Linux only supports SHSTK right now, so you may not want to advertise IBT support as there is no way to test it curr...
-
manx posted a comment on ticket #383
Maybe we need to go to inline asm, after all, at least for active architectures. I would suggest also considering to change to intrinsics instead of inline asm. Intrinsics for SSE and AVX on amd64 (or NEON on arm64) are widely supported and compatible between all major compilers, while inline asm requires compiler-specific syntax. We'd keep the files for 32 bit archs unchanged, I presume. Changing all the x86 32bit asm implementations is very likely not worth the effort, totally agreed.
-
Hm. You got a working example that does this in custom assembly files? Is the layout exactly the same on x86-64 as on ARM? What replaces __ARM_FEATURE_BTI_DEFAULT and __ARM_FEATURE_PAC_DEFAULT? I wonder how many of these annoying busywork items will crop up, making it more and more cumbersome to carry stand-alone assembly files. Maybe we need to go to inline asm, after all, at least for active architectures. We'd keep the files for 32 bit archs unchanged, I presume. But for now it is reasonable to...
-
libmpg123 is not compatible with SHSTK (Intel CET)
-
mpg123 released /mpg123/1.33.4/mpg123-1.33.4.tar.bz2
-
-
Ozkan Sezer posted a comment on ticket #382
Anyhow, I imported the most recent patch. Is current revision 5532 fine for you? Looks good to me
-
Isn't this a major bug in cmake and subprojects should just be avoided unless there is some isolation between them, or at least controlled sharing of variables? Anyhow, I imported the most recent patch. Is current revision 5532 fine for you?
-
Discard my big patch above. The following revised version of the Marteen's patch should do the trick: diff --git a/ports/cmake/src/CMakeLists.txt b/ports/cmake/src/CMakeLists.txt index 7861e35..f6a77b9 100644 --- a/ports/cmake/src/CMakeLists.txt +++ b/ports/cmake/src/CMakeLists.txt @@ -74,9 +74,9 @@ check_function_exists(execvp HAVE_EXECVP) check_function_exists(ctermid HAVE_CTERMID) check_function_exists(clock_gettime HAVE_CLOCK_GETTIME) -check_type_size(off_t SIZEOF_OFF_T) +check_type_size(off_t...
-
Maarten posted a comment on ticket #382
As an alternative, I've attached an alternative patch that changes all SIZEOF_OFF_T to MPG123_SIZEOF_OFF_T. This patch was created by @sezero, another member of the SDL project.
-
SIZEOF_OFF_T assertion error with cmake, mingw32, and mpg123 as a subproject
-
Attempting to build results in syntax error
-
mpg123 build failed for the avx assembly files.
-
out123_open uses strtok_r, which is unavailable on MSVC
-
Using libmpg123 to get raw ID3 returns modified data.
-
Building mpg123 using non-legacy CMake toolchain fails
-
-
-
Trunk works :)
-
This is a weird one. When I download the URL via wget, I get an MPEG stream. When I access via mpg123's old internal http code, I get some HTML reply. If I look at what the redirections that wget gets do … $ wget http://nrj.de/pop --2025-09-18 23:25:28-- http://nrj.de/pop Resolviendo nrj.de (nrj.de)... 157.90.170.233 Conectando con nrj.de (nrj.de)[157.90.170.233]:80... conectado. Petición HTTP enviada, esperando respuesta... 301 Moved Permanently Ubicación: https://frontend.streamonkey.net/energy-pop/stream/mp3?aggregator=shorty...
-
Hans Streibel created ticket #381
error: Unknown mpeg MIME type text/html
-
How's the current trunk for both?
-
You suggested using __ANDROID__ there. __ANDROID__ is a built-in macro, whereas ANDROID is added by the CMake toolchain file. Reading the verbose build log, -DANDROID is correctly passed when compiling C sources, but not when assembling S sources.
-
You suggested using __ANDROID__ there. __ANDROID__ is a built-in macro, whereas ANDROID is added by the CMake toolchain file. Reading the build log, Reading the verbose build log, -DANDROID is correctly passed when compiling C sources, but not when assembling S sources.
-
Am Wed, 10 Sep 2025 14:19:19 -0000 schrieb "Maarten" pacha2087@users.sourceforge.net: -.data +#ifndef APPLE + .section .rodata +#else + .data +#endif Yeah … I guess we probably should define a macro #ifndef __APPLE__ #define RODATA .section .rodata #else #define RODATA .data #endif and use that everywhere?
-
Am Wed, 10 Sep 2025 14:18:39 -0000 schrieb "Maarten" pacha2087@users.sourceforge.net: // Apple and Android NDK seem both not to like direct global access. -#if defined(PIC) && (defined(APPLE) || defined(ANDROID)) +#if defined(PIC) && (defined(APPLE) || defined(ANDROID)) #define PIC_GLOBAL_PTR #endif So our resolution of bug #345 was fauly in putting ANDROID in there? Or rather, this used to be defined and now only ANDROID is?
-
Unrelated to the error, but would this patch make sense? diff --git a/src/libmpg123/tabinit_mmx.S b/src/libmpg123/tabinit_mmx.S index 077e19e7..332bcd22 100644 --- a/src/libmpg123/tabinit_mmx.S +++ b/src/libmpg123/tabinit_mmx.S @@ -10,7 +10,11 @@ #include "mangle.h" -.data +#ifndef __APPLE__ + .section .rodata +#else + .data +#endif ALIGN32 .globl ASM_NAME(INT123_costab_mmxsse) ASM_NAME(INT123_costab_mmxsse):
-
Building mpg123 using non-legacy CMake toolchain fails
-
-
-
John Regan posted a comment on ticket #379
Just downloaded the latest snapshot and tested, and I can confirm the fix. Thank you so much!
-
It was a bad idea to begin with, messing with the bytes like that. I now took the step to change the internal parser API to pass the encoding separately, removing the need for the byte abusal. Revision 5520 contains the fix. The snapshot being generated before 03:00 CEST tonight will contain this. Can you confirm the fix?
-
Oh, right, you beat me to it. I even wrote a very explicit comment about abusing a byte.
-
Indeed. I did not spot the line yet, but something in the parser does modify the buffer. If you also set mpg123_param(mh, MPG123_ADD_FLAGS, MPG123_SKIP_ID3V2, 0); to disable the parsing itself (which makes sense if you are interested in the raw frame data), the contents are unchanged. Likely the parser modifying the data only started being a bug once we added the feature of keeping the RAW data
-
I believe the attached patch fixes the issue. There's some areas in id3.c that copy the encoding byte into the raw data when processing comments and usertext, this patch just makes sure to copy the original byte back.
-
Using libmpg123 to get raw ID3 returns modified data.
-
-
-
-
-
-
-
Camille Ribeiro posted a comment on ticket #378
Thank you, but now I can't do it, I was testing it on a friend's computer and they settled for using the pre-built version of mpg123 that came with their distribution of Ubuntu (no idea why apt worked but compiling it ourselves didn't). But again thanks for trying to fix it.
-
Can you try the same with current svn trunk? I added code that should give you a clearer error message (the error being missing pkg-config at autoreconf).
-
This happens whem you don't have JACK development files installed. No issue with running configure, but when generating it. (Edit: This was not supposed to be in bold, stupid sf.net markup) It's an annoyance, yes. Maybe we can change JACK detection not to depend on that macro. But for now, just install libjack-dev, jack-devel or similar package from your distribution. (Edit: removed mail signature … mail responses are a nice feature, but too bad that it's broken here.)
-
Ah, yes. It is about not having pkg-config installed when running autoreconf. Then all invokations of PKG_CHECK_MODULES stay in the configure script and the first one encountered causes this error. Seems to be a well-known and lamented issue that for some reason is not handled better. I wonder if I can do something to cause an error at autoconf time instead. Someone must have figured this out already, digging around a bit
-
Actually … I can't reproduce this right now. I remember such an issue, though. What did you do, exactly? Which download or repo checkout, which exact autoreconf invocation?
-
This happens whem you don't have JACK development files installed. No issue with running configure, but when generating it. It's an annoyance, yes. Maybe we can change JACK detection not to depend on that macro. But for now, just install libjack-dev, jack-devel or similar package from your distribution. sent from mobile device, trustworthy or not
-
Attempting to build results in syntax error
-
Pali posted a comment on ticket #375
So this is a libtool bug and should be reported there? I'm not very familiar with libtool and how it works for windows. But from your description it looks like that the file was autogenerated by libtool. And in this case it can be a bug in libtool. About encoding, it is hard to say. I do not know.
-
Yeah, except I don't find a declaration of putenv, let alone use of it in our sources. This is in files that start with /* src/.libs/lt-mpg123-strip.c - temporary wrapper executable for .libs/mpg123-strip.exe Generated by libtool (GNU libtool) 2.4.6 Debian-2.4.6-15build2 The src/mpg123-strip program cannot be directly executed until all the libtool libraries that it depends on are installed. This wrapper executable should never be moved out of the build directory. If it is, it will not operate correctly....
-
It looks like that you have own declaration of _putenv function in one of your source files, which is incompatible with the declaration already included from system header file. The best practice is to just include appropriate system header file and do not write own declaration of system functions. In this particular case the function declaration in your source file and in system header file differs on the __attribute__((dllimport)) keyword.
-
-
-
@Pali: During testing the changes, can you give some hint on that error cross-compiling with mingw-w64 on Linux? /bin/bash ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -O2 -fomit-frame-pointer -funroll-all-loops -finline-functions -ffast-math -Wall -Werror -std=c99 -pedantic -g -O2 -o src/mpg123.exe src/audio.o src/common.o src/sysutil.o src/control_generic.o src/equalizer.o src/getlopt.o src/httpget.o src/resolver.o src/genre.o src/mpg123.o src/metaprint.o src/local.o src/playlist.o src/streamdump.o...
-
Another update: I'm aiming at the small-scale return value handling now. The restructuring with wmain poses more questions and we lost our Windows maintainer over the somewhat heated discussions.
-
I committed the above now. Idea is to ship with 1.33.0. Edit: Using CCASFLAGS instead of CFLAGS
-
I committed the above now. Idea is to ship with 1.33.0.
-
Note: release 1.33.0 should ship with the fix.
-
fred vs posted a comment on ticket #278
Hello. I know, it is a old issue and I did have the same problem of the byte with error illegal entry. And that cause a delay/click in sound very boring. Even adding: mpg123_param(mh, MPG123_ICY_INTERVAL, 16000, 0) Till I read this: / Enumeration of the parameters types that it is possible to set/get. */ enum mpg123_parms .... MPG123_ICY_INTERVAL, /< Stream contains ICY metadata with this interval (integer). Make sure to set this before opening a stream.*/ mpg123_param(mh, MPG123_ICY_INTERVAL, 16000,...
-
So I guess something like Index: configure.ac =================================================================== --- configure.ac (revisión: 5475) +++ configure.ac (copia de trabajo) @@ -1209,7 +1209,7 @@ # extended to use balign if present AC_MSG_CHECKING([if .balign is present]) echo '.balign 4' > conftest.s -if $CCAS -c -o conftest.o conftest.s 1>/dev/null 2>&1; then +if $CCAS $CFLAGS -c -o conftest.o conftest.s 1>/dev/null 2>&1; then AC_MSG_RESULT([yes]) AC_DEFINE(ASMALIGN_BALIGN, 1, [ Define...
-
Regarding the cross compiler setup with/without CFLAGS, I am used to cross build setups where the toolchain carries that in the name, like arm-linux-gnueabihf-gcc … that will be the CC being used and it does not need options to activate target instruction suppot Edit: Same for arm-linux-gnueabihf-as, of course.
-
Regarding the cross compiler setup with/without CFLAGS, I am used to cross build setups where the toolchain carries that in the name, like arm-linux-gnueabihf-gcc … that will be the CC being used and it does not need options to activate target instruction suppot
-
Clarification about intsym.h: This is gone with mpg123 1.32. It used tp be present in src/. gcc -E -I. -I/Users/jenkins/workspace/cci_prod_PR-26381/conan-home/p/b/mpg1248a9c0de2a75d/b/src -I./src -DASMALIGN_BALIGN /Users/jenkins/workspace/cci_prod_PR-26381/conan-home/p/b/mpg1248a9c0de2a75d/b/src/src/libmpg123/dct36_avx.S | yasm - -pgas -rgas -mamd64 -f macho -o src/libmpg123/dct36_avx.o So the -I options pointing to your in/out of tree src should do the trick to locate it. Why not? Can you test that...
-
BalanceSoft modified a comment on ticket #377
Hi @sobukus, because add the (-arch x86_64) can let gcc to build x64 code on arm cpu, please refer to: https://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options so the check returns 'yes', and then the avx code is building by gcc, not need to use yasm, I think there are 2 issues: * The check function should also add the -arch x86_64 parameter (it's in CFLAGS). * If gcc can't work and selected yasm to build avx code, it's failed to work.
-
Hi @sobukus, because add the (-arch x86_64) can let gcc to build x64 code on arm cpu, so the check returns 'yes', and then the avx code is building by gcc, not need to use yasm, I think there are 2 issues: * The check function should also add the -arch x86_64 parameter (it's in CFLAGS). * If gcc can't work and selected yasm to build avx code, it's failed to work.
-
OK, the other way round. My head is not in good shape right now. Would it workkwhen the check is saying 'yes' for CCAS AVX support? I am puzzled myself how the intsym.h location crops up. I don't know if I'll have time to look into this on the weekend
-
Thanks @sobukus, The build is cross build, the cpu is armv8, the target arch x86_64(in Profile host): Profile host: [settings] arch=x86_64 Profile build: [settings] arch=armv8 conan team thought the configure script should add CFLAGS(-arch x86_64) when checking avx support to let CCAS work with cross build, please refer to: https://github.com/conan-io/conan-center-index/pull/26381
-
Thanks @sobukus, The build is cross build, the cpu is armv8, the target arch x86_64(in Profile host): Profile host: [settings] arch=x86_64 Profile build: [settings] arch=armv8 conan team thought the configure script should add CFLAGS when checking avx support, please refer to: https://github.com/conan-io/conan-center-index/pull/26381
-
Are you trying to build AVX for armv8 arch? No wonder that the compiler does not support it. Or am I grossly misreading the github issue? sent from mobile device, trustworthy or not
-
mpg123 build failed for the avx assembly files.
-
(not to self: read the chat history before posting) Apologies about the noise
-
Microsoft does not support 32-bit ARM in the latest Windows SDK. I can keep it building by using an older SDK version. https://github.com/madebr/mpg123/blob/6e06824f9bc16f4fc247a00c331b69c1f8148c4e/.github/workflows/CMake-MSVC.yml#L76
-
Ozkan: is the combined workflow missing something? I thought 32 bit ARM was missing, but I obviously missed it in the new combined workflow: So, my mistake, everything is OK.
-
is the combined workflow missing something? As far as I can see, only to old, now removed, noyasm workflow did not successfully build. See https://github.com/madebr/mpg123/actions/runs/12609590335 vs https://github.com/madebr/mpg123/actions/runs/12609590334 . This is because Microsoft removed 32bit ARM support in the latest SDK, and only the combined workflow accounts for that by explicitly selecting an older SDK for 32bit ARM. See https://github.com/madebr/mpg123/blob/b7db2283aa045699c53a788575...
-
I removed the redundant workflow now. Ozkan: is the combined workflow missing something?
-
You can remove .github/workflows/CMake-MSVC-noyasm.yml Yes. And it fails miserably already. Actually if fails because of that arm32 configuration (named amd64_arm in there) : LINK : fatal error LNK1104: cannot open file 'kernel32.lib' This is because of the win32 sdk version we had in SDL, no? Is this not fixable in mpg123 gh actions somehow?
-
You can remove .github/workflows/CMake-MSVC-noyasm.yml Yes. And it fails miserably already.
-
Indeed, all MSVC architectures are happy again! https://github.com/madebr/mpg123/actions You can remove .github/workflows/CMake-MSVC-noyasm.yml. .github/workflows/CMake-MSVC.yml tests mpg123 with and without yasm. https://github.com/madebr/mpg123/commit/c43addb5407f3eaa9c0050ea9c3fa0f3e07af4e2#diff-5decae584beea049114a705b5cf56e54c86c67d12349099f81b9ea98ec9b7427L1
-
OK, I should have fixed the strtok_r usage (now detecting and on MSVC hopefully using strtok_s) with revision 5474 and merged .github changes with 5475. Maybe you can confirm if things are right now
-
Just an update: We are intending to move away from wgetmainargs, and rather switch to setting UNICODE mode and using wmain for that case. It'll take some weeks because of holiday season.
-
weird warning when building against ARM64EC UCRT
-
"unresolved external symbol mpg123_open" when installing from vcpkg
-
FYI, I updated the GitHub workflows in the master-with-github-ci branch on my fork.
-
Yeah, I decided on UTF-8 internal representation, also in the library APIs, as one universal choice. Of course this comes from POSIX environments, where the upgrade path from 8 bit encodings via UTF-8 is the great cheap trick. Though, jumping to 16 bit wchar_t might also be considered a cheap trick, but a trick that failed once we had to move beyond UCS-2 into UTF-16, where you still have to deal with all the complexity of codepoint-vs-encoding-units … I do have to wonder how much the mpg123 application...
-
Thanks for info! It is really good to know for me what applications needs to do.
1 >
