mpg123-devel — Mailing list for mpg123 developers

Re: [mpg123-devel] Notion of SEEK_END

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

[on-list again, again]

Am 30. August 2023 23:11:34 MESZ schrieb Thomas Brand <to...@tr...>:

>>> Eventually a "seek_compatibility" flag could be introduced.  
>> 
>> This would need to be opt-in, though. We could introduce a flag
>> to fix SEEK_END behaviour. Or we could just document the state as-is
>> and realize that it's a rare case with not much practical impact.
>>   
>it's a hard decision. i don't know what's the best future-proof approach here.
>opt-in sounds good, plus documentation ..  

>> Hm. Returning an error or silently (only by return value) limiting offset
>> to the end. Both may make sense.  

I think it's simple after all. In a read-write library, seeking beyond
the end makes sense. You can write there and enlarge the file.
In a read-only library, only positions within the file make sense.

Current mpg123 inverts the sign of an offset from SEEK_END,
as I thought back then that it would be obvious to mean positive
steps from the end back. Only one direction does make sense.

So, what's the problem if I'd just ignore the sign of the SEEK_END
argument?

  mpg123_seek(mh, 128, SEEK_END)
  mpg123_seek(mh, -128, SEEK_END)

could both do the same thing. The latter would've been a error
with current libmpg123. Turning errors into valid behaviour has
its risks, but in this case, I think it is sensible.  


Alrighty then,

Thomas

Re: [mpg123-devel] Please test upcoming mpg123 1.32 (current snapshot or svn trunk)

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

Am Tue, 29 Aug 2023 17:04:50 +0000
schrieb Thomas Brand <to...@tr...>: 

> I'm not sure how gapless is related to seek, I couldn't pin it down.

It is related to seek, as it is concerned with exact sample offsets.
Things like

#ifdef GAPLESS
			else if(mh->end_os > 0) pos = SAMPLE_ADJUST(mh,mh->end_os) - sampleoff;
#endif

As only with gapless mode, things like the accurate sample count
including padding from the encoder are considered.

> PS, here the quick & dirty testcode:

You had me wondering for a moment. Non-gapless mode is not tested …
having it as an option stems from the time at that I did this one thing
to mpg123, hack in gapless decoding. This was my addition and I of course
wasn't sure how well it would work out. It was an option. It probably
should not be an option anymore.

To your testcase: Yes, seeking to 10 yields position 0. This is expected
once you realize (or have better documentation indicating) that without
the gapless machinery, libmpg123 seeking simply has no resolution below
MPEG frames. With a normal MP3 file that has 1152 samples per frame, you
should observe this:

#seek_to   result_gapless result_non-gapless
       0                0                   0
      10               10                   0
    1151             1151                   0
    1152             1152                1152

The non-gapless mode can only advance in full MPEG frames. This is what
mpg123 would do before I hacked in the gapless mode.

Now we indeed could discuss if, after all the years, we should get rid
of --disable-gapless.


Alrighty then,

Thomas

Re: [mpg123-devel] Notion of SEEK_END

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

Am Tue, 29 Aug 2023 17:21:23 +0000
schrieb Thomas Brand <to...@tr...>: 

> To seek 10 samples before the end, I'd seek(-10, SEEK_END), but this 
> overshoots by 10 samples (length + 10). On the other hand, seek(10, 
> SEEK_END) will go to 10 samples before the end. I think this notion is 
> inverse to other uses of SEEK_END.

Oh, great. Looking at lseek(2) and at my own documentation in mpg123.h,
the behaviour indeed does not match the description. It's utterly
wrong and you are the first person to notice.

Damn. I have to think hard on how to best handle it. Just correcting
the behaviour would break anyone relying on the existing. At the same
time, precisely because you're the first one noticing, I _guess_ that
you might be the only one trying to seek from the end on MPEG files so
far.

Having the reverse meaning compared to lseek really sucks. I don't have
the solution right now for the next release, just a confirmation that
you're right.


Alrighty then,

Thomas

[mpg123-devel] Notion of SEEK_END

[Thomas B. <to...@tr...>]

Hi, I'm puzzled with mpg123_seek() when using SEEK_END.
To seek 10 samples before the end, I'd seek(-10, SEEK_END), but this 
overshoots by 10 samples (length + 10). On the other hand, seek(10, 
SEEK_END) will go to 10 samples before the end. I think this notion is 
inverse to other uses of SEEK_END. Is it the expected behaviour? Unless 
I haven't overlooked something fundamental and my test is wrong, it 
should eventually be mentioned in the docs.
Greetings
Thomas

Re: [mpg123-devel] Please test upcoming mpg123 1.32 (current snapshot or svn trunk)

[Thomas B. <to...@tr...>]

On 2023-08-21 22:13, Thomas Orgis wrote:
> TL;DR: Test mpg123 snapshot on your platform and report breakage. 
> Please.
> 
> 
> So, give
> 
> 	https://mpg123.org/snapshot
> 
> a spin. The full list of NEWS scheduled for the upcoming release 
> contains
> some more points:
> 

Hello, I've gave it a spin (x86_64, Linux) and everything looks good so 
far. Only a small set of functions are involved so it might not be 
representative.

Something observed independently and most likely not related to the new 
snapshot is that when compile flag
--enable-gapless=no
is set, then mpg123_seek seems to not work. This also happens with for 
example 1.31.3. The effect is that a mpg123_seek(h, 10, SEEK_SET) will 
return 0.
When --enable-gapless=no is not set, it will return 10, nothing else 
changed.
I'm not sure how gapless is related to seek, I couldn't pin it down.

Greetings
Thomas


PS, here the quick & dirty testcode:
#include <stdio.h>
#include <mpg123.h>
#include <stdint.h>
#include <inttypes.h>

static mpg123_handle* mh;

//=====================================================
int main(int argc, char **argv)
{
	long rate;
	int channels, format, err;
	int64_t offset=10;
	int64_t pos=0;

	mpg123_init();
	mh = mpg123_new(NULL, NULL);
	mpg123_format_none (mh);
	format=mpg123_format(mh
		, 44100
		, MPG123_STEREO
		, MPG123_ENC_FLOAT_32
	);
	err = mpg123_open(mh, argv[1]);
	if(err == MPG123_OK)
	{
		mpg123_getformat(mh, &rate, &channels, &format);

		pos=mpg123_seek(mh,offset,SEEK_SET);
		fprintf(stderr, "seek end return %" PRId64 "\n", pos);

		mpg123_close(mh);
	}
	else{fprintf(stderr, "Failed to open file: %s\n", 
mpg123_strerror(mh));}

	mpg123_exit();
}

./configure
vs
./configure --enable-gapless=no

[mpg123-devel] Please test upcoming mpg123 1.32 (current snapshot or svn trunk)

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

TL;DR: Test mpg123 snapshot on your platform and report breakage. Please.

Dear all,

the lengthy dicussion on bug 344 prompted some hefty rearrangements in the
libmpg123 code and significant changes in the build. We have yet another overhaul
of the largefile support. The primary code path is now formed by API that is
fixed to offsets using int64_t and functions working with off_t (be it 32 bit
or 64 bit) are bolted on top of that. This enables work with large files
regardless of LFS in the libmpg123 build, which may be lacking in case of MSVC
builds that simply don't do 64 bit off_t, by client code providing proper
callbacks to

	mpg123_reader64( mpg123_handle *mh
	,	int (*r_read) (void *, void *, size_t, size_t *)
	,	int64_t (*r_lseek)(void *, int64_t, int)
	,	void (*cleanup)(void*) );

Whatever tricks your platform needs to do proper I/O, you can implement them.
I don't have to care. You can also define the macro MPG123_PORTABLE_API (same
for libsyn123 and syn123.h with SYN123_PORTABLE_API) when including mpg123.h to
skip defining any API that touches off_t (or ssize_t, for that matter).

The library is now built using explicit _LARGEFILE64_SOURCE and lseek64(), if
available. The standard autoconf largefile detection macro is not used anymore.
So it could well be that something needs consideration on platform X. I might
have assumed something that I shouldn't have.

So, give

	https://mpg123.org/snapshot

a spin. The full list of NEWS scheduled for the upcoming release contains
some more points:

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.
- 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
- 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.


Alrighty then,

Thomas

Re: [mpg123-devel] Question about mpg123_distversion()

[Thomas B. <to...@tr...>]

On 2023-08-06 11:27, Thomas Orgis wrote:
> Am Sun, 06 Aug 2023 10:29:10 +0200
> schrieb Thomas Orgis <tho...@or...>:
> 
>> I'll switch it over to a release branch, or generally have some
>> version info in there. Sorry for the confusion.
> 
> Or … actually … I kindof tried to prevent that confusion by this 
> preface:
> 
> 	Note: This API doc is automatically generated from the current
> 	development version that you can get via Subversion or as a
> 	daily snapshot from http://mpg123.org/snapshot. There may be
> 	differences (additions) compared to the latest stable release.
> 	See NEWS.libmpg123, NEWS.libout123, NEWS.libsyn123, and the
> 	overall NEWS file on libmpg123 versions and important changes
> 	between them.
> 
> I repaired the links to the NEWS files and spend a few minutes on
> adding mpg123 release version info to make them more useful for library
> feature lookup. See
> 
> 	https://mpg123.org/trunk/NEWS.libmpg123
> 
> for an overview of what is available with which mpg123 release. The
> version calls are scheduled for the next release series, 1.32.
> 
> Really nice would be to have a tag on each symbol on which version it
> appeared in. Maybe I'll script that into the doxygen stuff. Somehow I
> like that better than N copies of the documentation.
> 

Thanks for clarifying, it all makes sense now.
Greetings
Thomas

Re: [mpg123-devel] Question about mpg123_distversion()

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

Am Sun, 06 Aug 2023 10:29:10 +0200
schrieb Thomas Orgis <tho...@or...>: 

> I'll switch it over to a release branch, or generally have some
> version info in there. Sorry for the confusion.

Or … actually … I kindof tried to prevent that confusion by this preface:

	Note: This API doc is automatically generated from the current
	development version that you can get via Subversion or as a
	daily snapshot from http://mpg123.org/snapshot. There may be
	differences (additions) compared to the latest stable release.
	See NEWS.libmpg123, NEWS.libout123, NEWS.libsyn123, and the
	overall NEWS file on libmpg123 versions and important changes
	between them.

I repaired the links to the NEWS files and spend a few minutes on
adding mpg123 release version info to make them more useful for library
feature lookup. See

	https://mpg123.org/trunk/NEWS.libmpg123

for an overview of what is available with which mpg123 release. The
version calls are scheduled for the next release series, 1.32.

Really nice would be to have a tag on each symbol on which version it
appeared in. Maybe I'll script that into the doxygen stuff. Somehow I
like that better than N copies of the documentation.


Alrighty then,

Thomas

Re: [mpg123-devel] Question about mpg123_distversion()

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

I see ... the documentation is generated from the svn trunk, not the released version. The current development cycle with lots of API additions (and only intermittend developer time) coming up is dragging along and makes documentation go out of sync for too long.

I'll switch it over to a release branch, or generally have some version info in there. Sorry for the confusion.


Alrighty then,

Thomas

[mpg123-devel] Question about mpg123_distversion()

[Thomas B. <to...@tr...>]

Hello

I'm trying to call mpg123_distversion() and mpg123_libversion() like 
described here:

https://www.mpg123.de/api/group__mpg123__init.shtml#ga24c777432f0d27c07fd265a78647b3f2

fprintf(stderr, "mpg123 distversion: %s\n", mpg123_distversion(NULL, 
NULL, NULL));

But there's an undefined reference error. Grepping on the source tree 
(mpg123-1.31.3) doesn't reveal any matches for either distversion or 
libversion.

I'm missing something, what could be the issue? Thanks for any hints.

Greetings
Thomas

Re: [mpg123-devel] runtime detection of simd in libmpg123

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

Am Wed, 2 Aug 2023 08:06:02 +0200
schrieb Vincent Torri <vin...@gm...>: 

> i think that I have read somewhere that libmpg123 is doing runtime
> detection of simd
> 
> if it is true, can you tell me in which file ?

This is in the src/libmpg123/getcpuflags* files. Some assembly to get
registers, then flags to check in those.


Alrighty then,

Thomas

[mpg123-devel] runtime detection of simd in libmpg123

[Vincent T. <vin...@gm...>]

Hello

i think that I have read somewhere that libmpg123 is doing runtime
detection of simd

if it is true, can you tell me in which file ?

thank you

Vincent Torri

Re: [mpg123-devel] LGPL license violation on mobile versions of GTA San Andreas and more

[Alfredo C. <caj...@gm...>]

I just wanted to add some additional information, for any additional
copyright holders that may be monitoring the thread:

I've been able to verify that the following games are also in the same
violation as the previous games I already mentioned:

- Grand Theft Auto: Chinatown Wars for Android (available at Google Play
Store:
https://play.google.com/store/apps/details?id=com.rockstargames.gtactw )
- Bully: Scholarship Edition for Android (available at Google Play Store:
https://play.google.com/store/apps/details?id=com.rockstargames.bully )
- Max Payne Mobile for Android (available at Google Play Store:
https://play.google.com/store/apps/details?id=com.rockstar.maxpayne )

They all use the same version as the other games. It just seems they used
the same middleware for all of their mobile ports for each and every game.
With the same care as the already mentioned games in regard to LGPL code...

Regards,
C.

Re: [mpg123-devel] LGPL license violation on mobile versions of GTA San Andreas and more

[Thomas B. <to...@tr...>]

On 2023-07-10 21:17, Dave Yeo wrote:
> 
> Libsndfile is LGPL. Unluckily Erik, the principal author, seems to have 
> vanished. I'd guess other authors could object.
Hi,
Indeed, sorry for the confusion, it is effectively LGPL!

Re: [mpg123-devel] LGPL license violation on mobile versions of GTA San Andreas and more

[Dave Y. <dav...@gm...>]

On 07/10/23 10:32 AM, Thomas Brand wrote:
> On 2023-07-09 10:25, Alfredo Cajá wrote:
>> El dom, 9 jul 2023 a la(s) 08:32, Thomas Orgis (tho...@or...)
>> escribió:
>>
>>> That's annoying because it wouldn't be that hard to comply and still do
>>> business with the closed-source parts. Although: In the case of an
>>> Android/iOS app, it not so trivial for a user to replace the mpg123
>>> build in it (compared to switching a .dll file in Windows), but it's
>>> technically possible.
>>>
> Hi, that's an interesting topic, I was trying to understand the exact
> implications of LGPL libraries just recently and came to the conclusion
> that a legal use in non-licensed or incompatibly licensed code is only
> possible with external, e.g. not statically linked LGPL library.
> To ship a binary which is using the LGPL library, i understand it so
> that it can happily be shipped along the (e.g. close source) binary, iff
> the license is available and the source code of the exact library
> shipped is also made available. The unclear was if the library can be
> shipped along the binary or if it has to be already on a system or if it
> has to be installed in a separate process.

It is possible to ship a closed source program in object format along 
with the LGPL'ed library and a script or makefile to relink, allowing 
the library to be updated and relinked into the closed source program. 
Easier to use a DLL or shared library.
The library can be shipped with the closed source program along with 
source or an offer of the source.
There's also the case of open source program with an incompatible 
library, a MP3 player that uses OpenSSL for example, where it is easy to 
supply all source.
In all cases, the work must give prominent notice that it is using the 
LGPL work as well.

> As a side-note, the "files" app, which is pre-intsalled on iOS, recently
> revealed while fiddling, that it uses libsndfile. Which i found odd,
> since libsndfile is not even LGPL. It would mean that the "files" app is
> GPL'ed?

Libsndfile is LGPL. Unluckily Erik, the principal author, seems to have 
vanished. I'd guess other authors could object.

> Good luck Thomas hunting down the violators using the exceptional
> libmpg123.
> Greetings
> Thomas

Dave

Re: [mpg123-devel] LGPL license violation on mobile versions of GTA San Andreas and more

[Thomas B. <to...@tr...>]

On 2023-07-09 10:25, Alfredo Cajá wrote:
> El dom, 9 jul 2023 a la(s) 08:32, Thomas Orgis (tho...@or...)
> escribió:
> 
>> That's annoying because it wouldn't be that hard to comply and still 
>> do
>> business with the closed-source parts. Although: In the case of an
>> Android/iOS app, it not so trivial for a user to replace the mpg123
>> build in it (compared to switching a .dll file in Windows), but it's
>> technically possible.
>> 
Hi, that's an interesting topic, I was trying to understand the exact 
implications of LGPL libraries just recently and came to the conclusion 
that a legal use in non-licensed or incompatibly licensed code is only 
possible with external, e.g. not statically linked LGPL library.
To ship a binary which is using the LGPL library, i understand it so 
that it can happily be shipped along the (e.g. close source) binary, iff 
the license is available and the source code of the exact library 
shipped is also made available. The unclear was if the library can be 
shipped along the binary or if it has to be already on a system or if it 
has to be installed in a separate process.
As a side-note, the "files" app, which is pre-intsalled on iOS, recently 
revealed while fiddling, that it uses libsndfile. Which i found odd, 
since libsndfile is not even LGPL. It would mean that the "files" app is 
GPL'ed?
Good luck Thomas hunting down the violators using the exceptional 
libmpg123.
Greetings
Thomas

Re: [mpg123-devel] LGPL license violation on mobile versions of GTA San Andreas and more

[Alfredo C. <caj...@gm...>]

El dom, 9 jul 2023 a la(s) 08:32, Thomas Orgis (tho...@or...)
escribió:

> That's annoying because it wouldn't be that hard to comply and still do
> business with the closed-source parts. Although: In the case of an
> Android/iOS app, it not so trivial for a user to replace the mpg123
> build in it (compared to switching a .dll file in Windows), but it's
> technically possible.
>
Yeah, thought about expanding about the platform specific stuff just a bit
more:

On Android, the game itself is a shared library (basic ELF file, with .so
extension) which gets loaded by Java code, and then that code calls a
native function that works like main, which kinda just takes control from
there on and just goes back to Java to interface with eg. input and etc.
This library, the one with all the game specific code, has mpg123
statically linked into it.

This is pretty much the standard way to load native code on Android.
The developers of the port clearly already have dealt with using other
shared libraries, as they already use a separate shared library that
takes care of cloud saves.

One amusing fact: on some versions, they even ship a "OpenAL64.so"
file, but it doesn't get used because openal-soft was also statically linked
inside the main shared library. openal-soft is also an LGPL program! I'll
send a similar email later to the developers of openal-soft too.

iOS on the other hand is just a Mach-O executable. I don't know about
the specifics of loading shared libraries on Apple, but I trust Apple to
make it complicated somehow :P

This is a serious point. There is an earlier case of this from another
> popular game years ago, where a user reported the issue and I hoped
> that user has time to go forward with this. My understanding is that
> you as user who aquired the software have rights under LGPL and could
> claim violation. But the LGPL is not law itself, so the copyright
> holder has to do any litigation once users are denied their rights?
>
> I am thinking about the recent developments with Red Hat and the
> rebuilds. Technically, they don't have to make GPL/LPGL source code
> available to the public, but only to the customers of the binary
> software …
>
Yeah, I heard about that case too, that case specifically had me thinking
about that.


> I'm not against them making money, even with my code (among others') as
> part of that … but they should play by the rules.
>
I'm glad to hear that you don't feel too let down by it as long as it's by
the
rules.

… by which you mean do a legal purchase via Android/XBox/Windows/…
> stores? Depends on your juristidiction, I suppose, if just getting hold
> of the binaries some way counts.


Well, Rockstar/Take-Two likes to put a lot of legal speak on their EULA
for just being able to play the game. Stuff about not being allowed to
"decompile" the game (even though, at this point, with all the leftover
logging, you can just prove mpg123 by opening the library/executable on
a text editor and searching for mpg123!), and a bunch of legalese and
EULA stuff that may or may not be relevant to that. That, of course,
can also be a bunch of words that have the potential of not meaning
anything depending on your jurisdiction.

This also leads me to my other point:

I've verified that Grand Theft Auto: San Andreas for the PS3 also contains
mpg123 on it! Which means you should be able to grab a copy of it at any
time by simply getting the PS3 disk from ebay or etc. The other 2 games
(GTA 3 and GTA Vice City) weren't ported to consoles though (they might
be present on those, but they are emulated from their original PS2
versions).

This is of particular concern, since console APIs are under various NDAs
and whatnot. Usually LGPL/GPL compliance is thought impossible for
said platforms, since it would mean releasing sources or object files
related
to NDA-riddles sources/binaries. This is a very big blunder from everyone
involved in the process of making those versions!

In any case, in case it's needed at any point in time, I do have a Google
Play account with the games which I could provide if it's ever needed,
but I do strongly recommend that you get a hold of the games if possible.
Google Play Store and iOS is the most accessible version for the time
being, as well as PS3 physical media which is available for as long as
the disks work. The "Windows 8" UWP version was taken down long
ago at this point.

I'll have to ponder what to do. Any way forward probably would be
> through the SFC or similar.
>
Right, that sounds good. In any case:

I'm a user that's highly interested in either having access to the source
of the program which was linked against LGPL, or the necessary object files
to relink it with another version of mpg123. While it's possible that they
could correct the mobile versions, the files of the older versions were
already distributed, and PS3 in particular is impossible to correct because
Sony doesn't let you push updates anymore AFAIK, so I want to use the LGPL
rights in these versions.

I want to contact Rockstar and request them to deliver either of these, in
compliance with the LGPL license they have to comply with due to their use
of this LGPL library. I just wanted to make sure that if I did so, and they
just pulled the rug from under users wanting to use their LGPL rights by
taking digital versions down, the copyright holder of mpg123 also had the
game distributed to them (or at least have the opportunity of having the
game distributed even after a take down, which at this point should be
doable because of PS3 physical media), in case there's a breach of the
license, so that they may act upon it if they ever wanted to.

I just wanted to check with you, in case you are interested in acquiring
copies now or later in the future (at this point, they can take down the
digital versions, but the PS3 discs are physical media, they can't take
that away), and wanted to know if you were gonna acquire the games on
Google Play Store or acquire the PS3 disc now, or if you preferred to do
such a thing later and wouldn't mind users trying to use their LGPL users
now. In a perfect world I shouldn't be asking for such a thing, but given
the bad faith legal activity of Take-Two in recent times, I just want to be
extra sure.

Though, I think I'll just go ahead anyway, because the PS3 disc is there
forever (I had written the previous paragraphs before making the PS3
discovery...).
I'll let you know how it goes.

I wasn't quick enough moderating it. But I got a copy in my inbox.
>
Yeah, I did saw, but I just kinda wanted to make it less uncomplicated by
just making it a smaller email haha.

Anyways, I do hope the publisher does comply with LGPL by abiding to the
terms of it and doing what they're supposed to do with the current
versions, which is either source or object files for linking.
Thank you again for taking the time to reply.

Regards,
C.

El dom, 9 jul 2023 a la(s) 08:32, Thomas Orgis (tho...@or...)
escribió:

> Am Sun, 9 Jul 2023 06:01:57 +0200
> schrieb Alfredo Cajá <caj...@gm...>:
>
> > I wanted to let you know that there's ports of Grand Theft Auto games
> that
> > are violating the LGPL license
>
> Damn. Why don't they just adhere to the terms? I thought they got
> laywers who can read.
>
> > It's very easy to evidentiate the usage of mpg123 on the binaries I
> > verified:
>
> Indeed.
>
> > Considering that, I think it can be unequivocally stated that all of
> these
> > titles are in violation of the LGPL license for multiple reasons:
> > - No notice regarding LGPL code being in use anywhere in the game, stores
> > or etc..
> > - mpg123 source code, or instructions where to find it, nowhere to be
> found.
> > - The GTA games were never released under LGPL, and no object code has
> been
> > released that allows us as users to link GTA with our own version of
> mpg123.
>
> That's annoying because it wouldn't be that hard to comply and still do
> business with the closed-source parts. Although: In the case of an
> Android/iOS app, it not so trivial for a user to replace the mpg123
> build in it (compared to switching a .dll file in Windows), but it's
> technically possible.
>
> > That said, I strongly encourage developers who have copyright under
> mpg123
> > to acquire a copy of these games, so you have the chance to enforce LGPL,
> > since only the copyright owners who have received the offending software
> > can complain about license violations, and not 3rd parties.
>
> This is a serious point. There is an earlier case of this from another
> popular game years ago, where a user reported the issue and I hoped
> that user has time to go forward with this. My understanding is that
> you as user who aquired the software have rights under LGPL and could
> claim violation. But the LGPL is not law itself, so the copyright
> holder has to do any litigation once users are denied their rights?
>
> I am thinking about the recent developments with Red Hat and the
> rebuilds. Technically, they don't have to make GPL/LPGL source code
> available to the public, but only to the customers of the binary
> software …
>
> (Aside: I also had private discussion with a game studio exec one time
> about their lawyers having detected LGPL code in their game, wanting to
> negotiate a special license before release, which I am not comfortable
> granting, as I am not the exclusive copyright holder … just complying
> with the LGPL seems hard:-/)
>
> > I cannot imagine what reaction you would have, but probably not a
> positive
> > one considering these games have basically made millions while profiting
> > off LGPL source code without respecting the license at all.
>
> I'm not against them making money, even with my code (among others') as
> part of that … but they should play by the rules.
>
> > which is why I strongly suggested getting a copy
> > of the games ASAP
>
> … by which you mean do a legal purchase via Android/XBox/Windows/…
> stores? Depends on your juristidiction, I suppose, if just getting hold
> of the binaries some way counts.
>
>
> > I encourage you to try to ask for help  […]
> > https://www.gnu.org/licenses/gpl-violation.en.html
> > https://sfconservancy.org/
>
> > Please contact me in case you need more information
>
> I'll have to ponder what to do. Any way forward probably would be
> through the SFC or similar.
>
>
> Alrighty then,
>
> Thomas
>
> PS:
>
> > PS: My email didn't go through when I sent the screenshots as
> attachments,
>
> I wasn't quick enough moderating it. But I got a copy in my inbox.
>
>

Re: [mpg123-devel] LGPL license violation on mobile versions of GTA San Andreas and more

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

Am Sun, 9 Jul 2023 06:01:57 +0200
schrieb Alfredo Cajá <caj...@gm...>: 

> I wanted to let you know that there's ports of Grand Theft Auto games that
> are violating the LGPL license 

Damn. Why don't they just adhere to the terms? I thought they got
laywers who can read.

> It's very easy to evidentiate the usage of mpg123 on the binaries I
> verified:

Indeed.

> Considering that, I think it can be unequivocally stated that all of these
> titles are in violation of the LGPL license for multiple reasons:
> - No notice regarding LGPL code being in use anywhere in the game, stores
> or etc..
> - mpg123 source code, or instructions where to find it, nowhere to be found.
> - The GTA games were never released under LGPL, and no object code has been
> released that allows us as users to link GTA with our own version of mpg123.

That's annoying because it wouldn't be that hard to comply and still do
business with the closed-source parts. Although: In the case of an
Android/iOS app, it not so trivial for a user to replace the mpg123
build in it (compared to switching a .dll file in Windows), but it's
technically possible.

> That said, I strongly encourage developers who have copyright under mpg123
> to acquire a copy of these games, so you have the chance to enforce LGPL,
> since only the copyright owners who have received the offending software
> can complain about license violations, and not 3rd parties.

This is a serious point. There is an earlier case of this from another
popular game years ago, where a user reported the issue and I hoped
that user has time to go forward with this. My understanding is that
you as user who aquired the software have rights under LGPL and could
claim violation. But the LGPL is not law itself, so the copyright
holder has to do any litigation once users are denied their rights?

I am thinking about the recent developments with Red Hat and the
rebuilds. Technically, they don't have to make GPL/LPGL source code
available to the public, but only to the customers of the binary
software …

(Aside: I also had private discussion with a game studio exec one time
about their lawyers having detected LGPL code in their game, wanting to
negotiate a special license before release, which I am not comfortable
granting, as I am not the exclusive copyright holder … just complying
with the LGPL seems hard:-/)

> I cannot imagine what reaction you would have, but probably not a positive
> one considering these games have basically made millions while profiting
> off LGPL source code without respecting the license at all.

I'm not against them making money, even with my code (among others') as
part of that … but they should play by the rules.

> which is why I strongly suggested getting a copy
> of the games ASAP

… by which you mean do a legal purchase via Android/XBox/Windows/…
stores? Depends on your juristidiction, I suppose, if just getting hold
of the binaries some way counts.


> I encourage you to try to ask for help  […]
> https://www.gnu.org/licenses/gpl-violation.en.html
> https://sfconservancy.org/

> Please contact me in case you need more information

I'll have to ponder what to do. Any way forward probably would be
through the SFC or similar.


Alrighty then,

Thomas

PS:

> PS: My email didn't go through when I sent the screenshots as attachments,

I wasn't quick enough moderating it. But I got a copy in my inbox.

[mpg123-devel] LGPL license violation on mobile versions of GTA San Andreas and more

[Alfredo C. <caj...@gm...>]

Hi,

I wanted to let you know that there's ports of Grand Theft Auto games that
are violating the LGPL license from this project by statically linking
mpg123 into it. They're official ports developed by War Drum Studios LLC,
(now doing business as Grove Street Games), and published by Rockstar
Games, which is owned by Take-Two Interactive Software, Inc. and they're
still being sold today

Namely, I've been able to verify that mpg123 has statically linked against:

- Grand Theft Auto III for Android:
https://play.google.com/store/apps/details?id=com.rockstar.gta3&hl=en&gl=US
- Grand Theft Auto: Vice City for Android:
https://play.google.com/store/apps/details?id=com.rockstargames.gtavc&hl=en&gl=US
- Grand Theft Auto: San Andreas for Android:
https://play.google.com/store/apps/details?id=com.rockstargames.gtasa&hl=en&gl=US
- Grand Theft Auto: Liberty City Stories:
https://play.google.com/store/apps/details?id=com.rockstargames.gtalcs&hl=de&gl=IR
(currently unavailable in some territories)
- Grand Theft Auto III for iOS (can be found in iOS App Store)
- Grand Theft Auto SA for iOS (can be found in iOS App Store)

Other versions that I have not been able to verify, but I suspect might be
also in violation of the license:

- Grand Theft Auto Vice City for iOS (I haven't inspected this version yet,
but since it's in between GTA 3 and GTA SA, I'm positive it's there)
- PS3, Xbox 360, and Windows 8 Store ports of GTA 3, GTA VC and GTA SA

It's very easy to evidentiate the usage of mpg123 on the binaries I
verified:
- Logging from mpg123 source files, which also reveal the exact version in
use, mpg123-1.13.3 (attached a screenshot from IDA Disassembler - present
in Android and iOS)
- Debug symbols included on the release executable that match mpg123, as
well as clearly matching pseudocode (attached screenshot as well - Android
only)
- Debug information including complete structure and enum information from
mpg123 (attached screenshot as well - only on GTA San Andreas: for Android)

Considering that, I think it can be unequivocally stated that all of these
titles are in violation of the LGPL license for multiple reasons:
- No notice regarding LGPL code being in use anywhere in the game, stores
or etc..
- mpg123 source code, or instructions where to find it, nowhere to be found.
- The GTA games were never released under LGPL, and no object code has been
released that allows us as users to link GTA with our own version of mpg123.

That said, I strongly encourage developers who have copyright under mpg123
to acquire a copy of these games, so you have the chance to enforce LGPL,
since only the copyright owners who have received the offending software
can complain about license violations, and not 3rd parties.

I cannot imagine what reaction you would have, but probably not a positive
one considering these games have basically made millions while profiting
off LGPL source code without respecting the license at all. Some of these
ports have been released over 10 years at this point, but the latest
updates were just about a year ago and they still contain mpg123 on it.

I have no idea if Rockstar Games or Take-Two have been made aware of this.
Given their anti-consumer behaviour the past years, I do not know how much
luck you will have with this other than an attempt to try to hide the
situation under the rug, which is why I strongly suggested getting a copy
of the games ASAP, so that they don't take down the games before you're
able to acquire them to attempt to avoid LGPL compliance. I may be a bit
biased, but considering their past behavior, including litigating against
reverse engineers that aimed to fix the game (search online about the re3
and reVC case to see a good example of their bad faith actions), I don't
think they should be given the benefit of doubt, which is why I recommend
acquiring the games as well. In any case, this is a clear LGPL violation
and they should be made to comply with the license.

I encourage you to try to ask for help in assistance to how enforce
compliance. The Free Softwaree Foundation "offers assistance and advice to
any other copyright holder who wishes to enforce GNU licenses":
https://www.gnu.org/licenses/gpl-violation.en.html - The Software Freedom
Conservancy has also been willing to help with these kinds of matters,
going up to even funding a lawsuit for GPL violations:
https://sfconservancy.org/

Please contact me in case you need more information, such as binaries, more
details, or if there's any other details that you may want to know. My
email is caj...@gm...

Regards,
C.

PS: My email didn't go through when I sent the screenshots as attachments,
so I'll include this imgur album instead, which has the screenshots I
mentioned before: https://imgur.com/a/8SxkluR
Please ignore any "+18" warning imgur may display too - they're just
screenshots from IDA Pro!

[mpg123-devel] 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

[mpg123-devel] releasing mpg123 1.31.2 (just build fixes)

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

Dear people who eye mpg123,

there is not much to see here, but what there is, is this:

1.31.2
------
- Fix build --with-network=internal only (configure logic error, bug 348).
- Fix OS/2 build with getaddrinfo() (which may support IPv6 eventually, thanks
  to Dave Yeo).

Mpg123 1.31.2 can be fetched from the usual places … but if your build
worked, you do not have much reason to replace it.


Alrighty then,

Thomas

Re: [mpg123-devel] mpg123 1.31.0 released

[Dave Y. <dav...@gm...>]

On 01/12/23 12:09 AM, Thomas Orgis wrote:
> Am Wed, 11 Jan 2023 18:37:41 -0800
> schrieb Dave Yeo <dav...@gm...>:
>
>> OK, it seems that getaddrinfo() is expected to support ipv6. Perhaps
>> something like this would be better, it compiles and works.
>
>>                  os2)
>> +                        have_ipv6=no
>
> Well … do you ever expect OS/2 getaddrinfo() to support IPv6? Why was
> this API added, anyway? If the other variant builds and maybe starts
> supporting IPv6 later on, it might be preferrable.

IPv6 is on the roadmap, very low priority currently. It would mean a new 
TCPIP stack, not easy though our ancient stack is coming up to its 
limits when it comes to transfer speed with 1GB connections.
The API was added to make porting easier, adding an include is easier 
with software that expects getaddrinfo().

>
> But this maybe comes down to the question: Do we expect OS/2 to get
> further features added? I must admit I feel a bit silly asking that in
> the year 2023, but here we are;-)

Sure, currently testing UEFI boot, which along with GPT support is 
mostly done except the documentation. Secure boot is possible as well, 
still need the tools to easily add the keys to the BIOS, a release or 
two way.
This is actually ArcaOS, an OEM version of OS/2, 
https://www.arcanoae.com/ which has the goal of installing on modern 
hardware, which it does surprisingly well for an old 32 bit OS.
Dave

Re: [mpg123-devel] mpg123 1.31.0 released

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

Am Wed, 11 Jan 2023 18:37:41 -0800
schrieb Dave Yeo <dav...@gm...>: 

> OK, it seems that getaddrinfo() is expected to support ipv6. Perhaps 
> something like this would be better, it compiles and works.  

>                  os2)
> +                        have_ipv6=no  

Well … do you ever expect OS/2 getaddrinfo() to support IPv6? Why was
this API added, anyway? If the other variant builds and maybe starts
supporting IPv6 later on, it might be preferrable.

But this maybe comes down to the question: Do we expect OS/2 to get
further features added? I must admit I feel a bit silly asking that in
the year 2023, but here we are;-)


Alrighty then,

Thomas

-- 
GPG public key 60D5CAFE: https://thomas.orgis.org/public_key
Fingerprint: D021 FF8E CF4B E097 19D6  1A27 231C 4CBC 60D5 CAFE
And despite all of you, I'm still doing it. Yes, I do write Perl code.

Re: [mpg123-devel] mpg123 1.31.0 released

[Dave Y. <dav...@gm...>]

On 01/09/23 03:14 PM, Thomas Orgis wrote:
> Thanks,
>
> to clarify:
>
Hi,
> Am Sun, 8 Jan 2023 20:06:11 -0800
> schrieb Dave Yeo <dav...@gm...>:
>
>> OS/2 needs this patch to find getaddrinfo() and friends. No ipv6 support.
>
> You mean no IPv6 support before or still after this change? Do you have
> a complete build failure without libcx/net.h?
>

OK, it seems that getaddrinfo() is expected to support ipv6. Perhaps 
something like this would be better, it compiles and works.
Dave

Index: configure.ac
===================================================================
--- configure.ac        (revision 5205)
+++ configure.ac        (working copy)
@@ -1977,6 +1977,7 @@
                         fi
                 ;;
                 os2)
+                        have_ipv6=no
                         OS2_LIBS="-lcx -lmmpm2"
                         OS2_CFLAGS="-idirafter 
/@unixroot/usr/include/os2tk45"
                         oldcflags="$CFLAGS"

Re: [mpg123-devel] mpg123 1.31.0 released

[Dave Y. <dav...@gm...>]

On 01/09/23 03:14 PM, Thomas Orgis wrote:
> Thanks,
>
> to clarify:
>
> Am Sun, 8 Jan 2023 20:06:11 -0800
> schrieb Dave Yeo <dav...@gm...>:
>
>> OS/2 needs this patch to find getaddrinfo() and friends. No ipv6 support.
> You mean no IPv6 support before or still after this change? Do you have
> a complete build failure without libcx/net.h?

No ipv6 support at all, the getaddrinfo() test is sorta misnamed, not a 
big deal.
Yes, the failure,
../mpg123.svn/src/resolver.c:317:21: error: dereferencing pointer to 
incomplete type 'struct addrinfo'
   317 |   sock = socket(addr->ai_family, addr->ai_socktype, 
addr->ai_protocol);
       |                     ^~
../mpg123.svn/src/resolver.c:330:2: warning: implicit declaration of 
function 'freeaddrinfo' [-Wimplicit-function-declaration]
   330 |  freeaddrinfo(addrlist);
       |  ^~~~~~~~~~~~
make: *** [src/resolver.o] Error 1

Thanks,
Dave