mpg123-users — Mailing list for users of mpg123

Re: [mpg123-users] Trying to use remote mode from a CGI program

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

Am Wed, 31 Mar 2021 21:56:18 -0400
schrieb Alan Corey <ala...@gm...>: 

> some remote capabilities including pause/unpause and I'm trying to
> access that.

Ah, some basic misunderstanding. The remote control doesn't work via
command line, but standard input or a UNIX socket (FIFO). My
recommendation is to start mpg123 in the background using

	mpg123 -R --fifo /dev/shm/mpg123.socket

Then, you can issue commands like

	echo help > /dev/shm/mpg123.socket

and obviously

	echo load /path/to/file > /dev/shm/mpg123.socket

and as well

	echo pause > /dev/shm/mpg123.socket
.

You can capture the output of the mpg123 process to display progress
information somehow (but take care not to keep an ever-growing file of
that).

Access to the socket is controlled using normal UNIX permissions.


Alrighty then,

Thomas


PS: Some history: I only became mpg123 maintainer because I was doing
something similar around 2004 or so, a web frontend to our local music
archive. It used a backgrounded script that does playlist management
and worked on an instance of mixplayd, which started mpg123 processes.
I replaced mixplayd eventually with my own dermixd, which relies on the
remote control interface of mpg123, which I extended for better use …
and these extensions lead to me taking over development of mpg123.
If you don't need mixing of tracks, a single instance of mpg123 with
the remote interface does the trick. And I still need to get around
reworking dermixd to make more use of the building blocks I provide now
with mpg123 (libsyn123, namely).

Re: [mpg123-users] A round of testing of upcoming mpg123 1.27.0, please.

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

Am 31. März 2021 22:10:32 MESZ schrieb Alan Corey <ala...@gm...>:
>OK, it runs fine here.  Debian Bullseye on a Pinebook Pro laptop.
>Want a test on a Raspberry Pi (3B)?  ZeroW?

Any variation is good (mainly, 32 bit and 64 bit, nofpu, neon ... see --with-cpu for configure).


Alrighty then,

Thomas

Re: [mpg123-users] A round of testing of upcoming mpg123 1.27.0, please.

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

Thanks! Things looking good so far.

Am 1. April 2021 01:30:57 MESZ schrieb Martin Guy <mar...@gm...>:

>This laptop has 3DNow in its cpu; does the vanilla build use that or
>do I need to compile -mcpu=native?

On x86, it's a runtime choice. See

mpg123 --test-cpu

You can give the cpu parameter to the compliance script, just append --cpu foo.

It would be reassuring to have confirmation for 3dnow, mmx, sse. Also if you notice any speed difference (time mpg123 --cpu foo --loop n  some_file.mp3  against your /usr/bin/mpg123).


Alrighty then,

Thomas

[mpg123-users] Trying to use remote mode from a CGI program

[Alan C. <ala...@gm...>]

I've been mulling over in my head whether this is possible or not.  I
have a program that generates web pages which call mpg123 by a link as
the URL which feeds numbers to a CGI program, the CGI program then
calls mpg123 passing it a file path.
https://cgi-jukebox.sourceforge.io/

Among the things I'd like to add to it is a pause liink.  mpg123 has
some remote capabilities including pause/unpause and I'm trying to
access that.  mpg123 and my cgi program block while a song is playing
I'm pretty sure because for the duration of the song the browser looks
like the page is trying to load.  So I think I should be able to
access the remote mode during this.  Except when I try to pass a P I
get an error that looks like it's trying to open a file named P:

This appears in the Apache error log:
[src/libmpg123/readers.c:1204] error: Cannot open file P: No such file
or directory
main: [src/mpg123.c:738] error: Cannot open P: File access error. (code 22)

I tried briefly passing a space and got nowhere.

My dopause function, called by a P as the first argument to the CGI program is

void dopause(void) {
  int rnum;
  char cmd[100];
  snprintf(cmd,100,"mpg123 P &> /dev/null");
  rnum = atoi(&cgidata[2]); // past the P and ?
  system(cmd);
  snprintf(retn,STRINGLEN,"%s/%0*i.html",WEB,DIGITS,rnum);
  printf("Location: %s\n\n",retn);
}
retn is defined globally, it's just a string for the URL the browser
should return to , it wants to go somewhere.  I usually send the URL
of the page it started on which works for other things.

A typical pause link looks like
<a href='http://pbp/cgi-bin/jbe?P?00000080'>Pause</a>&#160;</P>

I guess my question is whether this is likely to work if I get
everything right.  I can pass commands to the CGI program which call
amixer to change the volume while a song is playing so that's not
blocked.  Seems like I should be able to pause mpg123 the same way.
Or should I send it something other than P?  Or is at a question of
the process number mpg123 sees as being wrong?  The CGI program is
normally transient except it's waiting for mpg123 to finish the song
and return.
-- 
-------------
Education is contagious.

Re: [mpg123-users] A round of testing of upcoming mpg123 1.27.0, please.

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

> What about proper 32 bit x86 machines

playing swoop.mp3 and compliance.pl all OK on 32-bit Debian i386

> what about 3DNow

This laptop has 3DNow in its cpu; does the vanilla build use that or
do I need to compile -mcpu=native?

    M

Re: [mpg123-users] A round of testing of upcoming mpg123 1.27.0, please.

[Alan C. <ala...@gm...>]

OK, it runs fine here.  Debian Bullseye on a Pinebook Pro laptop.
Want a test on a Raspberry Pi (3B)?  ZeroW?


==== Layer 1 ====
--> 16 bit signed integer output
fl1.bit:	RMS=4.364373e-06 (PASS) maxdiff=7.629395e-06 (PASS)
fl2.bit:	RMS=4.353138e-06 (PASS) maxdiff=7.629395e-06 (PASS)
fl3.bit:	RMS=4.348759e-06 (PASS) maxdiff=7.688999e-06 (PASS)
fl4.bit:	RMS=4.403421e-06 (PASS) maxdiff=7.629395e-06 (PASS)
fl5.bit:	RMS=4.323457e-06 (PASS) maxdiff=7.688999e-06 (PASS)
fl6.bit:	RMS=4.389613e-06 (PASS) maxdiff=7.688999e-06 (PASS)
fl7.bit:	RMS=3.826083e-06 (PASS) maxdiff=7.629395e-06 (PASS)
fl8.bit:	RMS=4.362205e-06 (PASS) maxdiff=7.629395e-06 (PASS)
--> 32 bit integer output
fl1.bit:	RMS=1.965337e-08 (PASS) maxdiff=1.508743e-07 (PASS)
fl2.bit:	RMS=1.972273e-08 (PASS) maxdiff=1.117587e-07 (PASS)
fl3.bit:	RMS=2.002190e-08 (PASS) maxdiff=1.359731e-07 (PASS)
fl4.bit:	RMS=1.900039e-08 (PASS) maxdiff=1.303852e-07 (PASS)
fl5.bit:	RMS=3.680735e-08 (PASS) maxdiff=1.192093e-07 (PASS)
fl6.bit:	RMS=3.061235e-08 (PASS) maxdiff=1.639128e-07 (PASS)
fl7.bit:	RMS=1.766694e-08 (PASS) maxdiff=8.009374e-08 (PASS)
fl8.bit:	RMS=1.855443e-08 (PASS) maxdiff=8.661300e-08 (PASS)
--> 24 bit integer output
fl1.bit:	RMS=4.096526e-08 (PASS) maxdiff=1.192093e-07 (PASS)
fl2.bit:	RMS=4.151559e-08 (PASS) maxdiff=1.192093e-07 (PASS)
fl3.bit:	RMS=4.121270e-08 (PASS) maxdiff=1.788139e-07 (PASS)
fl4.bit:	RMS=4.103930e-08 (PASS) maxdiff=1.192093e-07 (PASS)
fl5.bit:	RMS=4.476811e-08 (PASS) maxdiff=1.192093e-07 (PASS)
fl6.bit:	RMS=3.920660e-08 (PASS) maxdiff=1.788139e-07 (PASS)
fl7.bit:	RMS=4.186392e-08 (PASS) maxdiff=1.192093e-07 (PASS)
fl8.bit:	RMS=4.094408e-08 (PASS) maxdiff=1.192093e-07 (PASS)
--> 32 bit floating point output
fl1.bit:	RMS=1.965340e-08 (PASS) maxdiff=1.508743e-07 (PASS)
fl2.bit:	RMS=1.972263e-08 (PASS) maxdiff=1.117587e-07 (PASS)
fl3.bit:	RMS=2.002196e-08 (PASS) maxdiff=1.359731e-07 (PASS)
fl4.bit:	RMS=1.900029e-08 (PASS) maxdiff=1.303852e-07 (PASS)
fl5.bit:	RMS=3.680734e-08 (PASS) maxdiff=1.192093e-07 (PASS)
fl6.bit:	RMS=3.061236e-08 (PASS) maxdiff=1.639128e-07 (PASS)
fl7.bit:	RMS=1.766678e-08 (PASS) maxdiff=8.009374e-08 (PASS)
fl8.bit:	RMS=1.855437e-08 (PASS) maxdiff=8.661300e-08 (PASS)

==== Layer 2 ====
--> 16 bit signed integer output
fl10.bit:	RMS=3.512100e-06 (PASS) maxdiff=7.629395e-06 (PASS)
fl11.bit:	RMS=3.837267e-06 (PASS) maxdiff=7.629395e-06 (PASS)
fl12.bit:	RMS=3.901071e-06 (PASS) maxdiff=7.629395e-06 (PASS)
fl13.bit:	RMS=4.379583e-06 (PASS) maxdiff=7.629395e-06 (PASS)
fl14.bit:	RMS=4.112584e-06 (PASS) maxdiff=7.688999e-06 (PASS)
fl15.bit:	RMS=4.388568e-06 (PASS) maxdiff=7.688999e-06 (PASS)
fl16.bit:	RMS=4.147489e-06 (PASS) maxdiff=7.629395e-06 (PASS)
--> 32 bit integer output
fl10.bit:	RMS=1.775839e-08 (PASS) maxdiff=8.288771e-08 (PASS)
fl11.bit:	RMS=1.788156e-08 (PASS) maxdiff=9.685755e-08 (PASS)
fl12.bit:	RMS=1.780182e-08 (PASS) maxdiff=8.195639e-08 (PASS)
fl13.bit:	RMS=1.761837e-08 (PASS) maxdiff=4.470348e-08 (PASS)
fl14.bit:	RMS=3.567069e-08 (PASS) maxdiff=1.192093e-07 (PASS)
fl15.bit:	RMS=2.402172e-08 (PASS) maxdiff=1.937151e-07 (PASS)
fl16.bit:	RMS=1.921122e-08 (PASS) maxdiff=1.490116e-07 (PASS)
--> 24 bit integer output
fl10.bit:	RMS=4.081199e-08 (PASS) maxdiff=1.192093e-07 (PASS)
fl11.bit:	RMS=4.088804e-08 (PASS) maxdiff=1.192093e-07 (PASS)
fl12.bit:	RMS=4.089575e-08 (PASS) maxdiff=1.192093e-07 (PASS)
fl13.bit:	RMS=4.104971e-08 (PASS) maxdiff=5.960464e-08 (PASS)
fl14.bit:	RMS=4.424844e-08 (PASS) maxdiff=1.192093e-07 (PASS)
fl15.bit:	RMS=4.069500e-08 (PASS) maxdiff=2.384186e-07 (PASS)
fl16.bit:	RMS=4.143382e-08 (PASS) maxdiff=1.788139e-07 (PASS)
--> 32 bit floating point output
fl10.bit:	RMS=1.775831e-08 (PASS) maxdiff=8.288771e-08 (PASS)
fl11.bit:	RMS=1.788157e-08 (PASS) maxdiff=9.685755e-08 (PASS)
fl12.bit:	RMS=1.780182e-08 (PASS) maxdiff=8.195639e-08 (PASS)
fl13.bit:	RMS=1.761831e-08 (PASS) maxdiff=4.470348e-08 (PASS)
fl14.bit:	RMS=3.567069e-08 (PASS) maxdiff=1.192093e-07 (PASS)
fl15.bit:	RMS=2.402166e-08 (PASS) maxdiff=1.937151e-07 (PASS)
fl16.bit:	RMS=1.921095e-08 (PASS) maxdiff=1.490116e-07 (PASS)

==== Layer 3 ====
--> 16 bit signed integer output
compl.bit:	RMS=4.300912e-06 (PASS) maxdiff=7.688999e-06 (PASS)
--> 32 bit integer output
compl.bit:	RMS=2.109915e-08 (PASS) maxdiff=1.862645e-07 (PASS)
--> 24 bit integer output
compl.bit:	RMS=4.174315e-08 (PASS) maxdiff=1.788139e-07 (PASS)
--> 32 bit floating point output
compl.bit:	RMS=2.109916e-08 (PASS) maxdiff=1.862645e-07 (PASS)

==== Layer 3 intensity stereo ====
   (no official reference, comparing to mpg123 generic 24 bit)
--> 16 bit signed integer output
drumshort08kHz.bit:	RMS=4.348721e-06 (PASS) maxdiff=7.748604e-06 (PASS)
drumshort24kHz.bit:	RMS=4.366034e-06 (PASS) maxdiff=7.808208e-06 (PASS)
drumshort48kHz.bit:	RMS=4.375121e-06 (PASS) maxdiff=8.285046e-06 (PASS)
--> 32 bit integer output
drumshort08kHz.bit:	RMS=3.585401e-08 (PASS) maxdiff=3.278255e-07 (PASS)
drumshort24kHz.bit:	RMS=3.739923e-08 (PASS) maxdiff=4.619360e-07 (PASS)
drumshort48kHz.bit:	RMS=4.149264e-08 (PASS) maxdiff=1.009554e-06 (PASS)
--> 24 bit integer output
drumshort08kHz.bit:	RMS=2.112026e-08 (PASS) maxdiff=2.980232e-07 (PASS)
drumshort24kHz.bit:	RMS=2.398265e-08 (PASS) maxdiff=4.768372e-07 (PASS)
drumshort48kHz.bit:	RMS=3.045763e-08 (PASS) maxdiff=1.013279e-06 (PASS)
--> 32 bit floating point output
drumshort08kHz.bit:	RMS=3.585409e-08 (PASS) maxdiff=3.278255e-07 (PASS)
drumshort24kHz.bit:	RMS=3.739921e-08 (PASS) maxdiff=4.619360e-07 (PASS)
drumshort48kHz.bit:	RMS=4.149262e-08 (PASS) maxdiff=1.009554e-06 (PASS)


On 3/31/21, Thomas Orgis <tho...@or...> wrote:
>
>
> Am 31. März 2021 20:23:43 MESZ schrieb Alan Corey <ala...@gm...>:
>>I guess I flunk, I don't see a new mpg123 biinary.  This is building
>>on aarch64, log file made with tee.
>
> That's one of the arches to test ...
>
>>cc -Wall -Werror -g -O2 -o rmsdouble.bin rmsdouble.c -lm
>> [...]
>>./hex24_double.bin < compliance/layer3is/drumshort48kHz.hex >
>>compliance/layer3is/drumshort48kHz.double
>
> Well, you got the compliance test infrastructure built.
> Now just combine that with a fresh ./configure && make
> on
>
> https://mpg123.org/snapshot
>
> and you hopefully have the mpg123 binary to test (via src/mpg123).
>
>
> Alrighty then,
>
> Thomas
>


-- 
-------------
Education is contagious.

Re: [mpg123-users] A round of testing of upcoming mpg123 1.27.0, please.

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

Am 31. März 2021 20:23:43 MESZ schrieb Alan Corey <ala...@gm...>:
>I guess I flunk, I don't see a new mpg123 biinary.  This is building
>on aarch64, log file made with tee.

That's one of the arches to test ... 

>cc -Wall -Werror -g -O2 -o rmsdouble.bin rmsdouble.c -lm
> [...]
>./hex24_double.bin < compliance/layer3is/drumshort48kHz.hex >
>compliance/layer3is/drumshort48kHz.double

Well, you got the compliance test infrastructure built.
Now just combine that with a fresh ./configure && make
on

https://mpg123.org/snapshot

and you hopefully have the mpg123 binary to test (via src/mpg123).


Alrighty then,

Thomas

Re: [mpg123-users] A round of testing of upcoming mpg123 1.27.0, please.

[Alan C. <ala...@gm...>]

I guess I flunk, I don't see a new mpg123 biinary.  This is building
on aarch64, log file made with tee.

cc -Wall -Werror -g -O2 -o rmsdouble.bin rmsdouble.c -lm
cc -Wall -Werror -g -O2 -o rms16.bin rms16.c -lm
cc -Wall -Werror -g -O2 -DS16 -o s16_double.bin to_double.c -lm
cc -Wall -Werror -g -O2 -DF32 -o f32_double.bin to_double.c -lm
cc -Wall -Werror -g -O2 -DS32 -o s32_double.bin to_double.c -lm
cc -Wall -Werror -g -O2 -DMPGTEST_LITTLE_ENDIAN -o s24_double.bin
s24_to_double.c -lm
cc -Wall -Werror -g -O2 -o hex24_double.bin hex24_double.c -lm
cc -Wall -Werror -g -O2 -o hex_bitstream.bin hex_bitstream.c -lm
cc -Wall -Werror -g -O2 -o buffer.bin buffer.c -lm
echo bin > binsuffix
./hex_bitstream.bin < compliance/layer1/fl1.mpg > compliance/layer1/fl1.bit
./hex_bitstream.bin < compliance/layer1/fl2.mpg > compliance/layer1/fl2.bit
./hex_bitstream.bin < compliance/layer1/fl3.mpg > compliance/layer1/fl3.bit
./hex_bitstream.bin < compliance/layer1/fl4.mpg > compliance/layer1/fl4.bit
./hex_bitstream.bin < compliance/layer1/fl5.mpg > compliance/layer1/fl5.bit
./hex_bitstream.bin < compliance/layer1/fl6.mpg > compliance/layer1/fl6.bit
./hex_bitstream.bin < compliance/layer1/fl7.mpg > compliance/layer1/fl7.bit
./hex_bitstream.bin < compliance/layer1/fl8.mpg > compliance/layer1/fl8.bit
./hex_bitstream.bin < compliance/layer2/fl10.mpg > compliance/layer2/fl10.bit
./hex_bitstream.bin < compliance/layer2/fl11.mpg > compliance/layer2/fl11.bit
./hex_bitstream.bin < compliance/layer2/fl12.mpg > compliance/layer2/fl12.bit
./hex_bitstream.bin < compliance/layer2/fl13.mpg > compliance/layer2/fl13.bit
./hex_bitstream.bin < compliance/layer2/fl14.mpg > compliance/layer2/fl14.bit
./hex_bitstream.bin < compliance/layer2/fl15.mpg > compliance/layer2/fl15.bit
./hex_bitstream.bin < compliance/layer2/fl16.mpg > compliance/layer2/fl16.bit
./hex24_double.bin < compliance/layer1/fl1.pcm > compliance/layer1/fl1.double
./hex24_double.bin < compliance/layer1/fl2.pcm > compliance/layer1/fl2.double
./hex24_double.bin < compliance/layer1/fl3.pcm > compliance/layer1/fl3.double
./hex24_double.bin < compliance/layer1/fl4.pcm > compliance/layer1/fl4.double
./hex24_double.bin < compliance/layer1/fl5.pcm > compliance/layer1/fl5.double
./hex24_double.bin < compliance/layer1/fl6.pcm > compliance/layer1/fl6.double
./hex24_double.bin < compliance/layer1/fl7.pcm > compliance/layer1/fl7.double
./hex24_double.bin < compliance/layer1/fl8.pcm > compliance/layer1/fl8.double
./hex24_double.bin < compliance/layer2/fl10.pcm > compliance/layer2/fl10.double
./hex24_double.bin < compliance/layer2/fl11.pcm > compliance/layer2/fl11.double
./hex24_double.bin < compliance/layer2/fl12.pcm > compliance/layer2/fl12.double
./hex24_double.bin < compliance/layer2/fl13.pcm > compliance/layer2/fl13.double
./hex24_double.bin < compliance/layer2/fl14.pcm > compliance/layer2/fl14.double
./hex24_double.bin < compliance/layer2/fl15.pcm > compliance/layer2/fl15.double
./hex24_double.bin < compliance/layer2/fl16.pcm > compliance/layer2/fl16.double
./hex24_double.bin < compliance/layer3/compl.hex >
compliance/layer3/compl.double
./hex24_double.bin < compliance/layer3is/drumshort08kHz.hex >
compliance/layer3is/drumshort08kHz.double
./hex24_double.bin < compliance/layer3is/drumshort24kHz.hex >
compliance/layer3is/drumshort24kHz.double
./hex24_double.bin < compliance/layer3is/drumshort48kHz.hex >
compliance/layer3is/drumshort48kHz.double


On 3/31/21, Thomas Orgis <tho...@or...> wrote:
> Hi folks,
>
> There are some core changes in libmpg123 scheduld for the next feature
> release. Following work by Taihei on the fixed-point decoders, all
> common decoding tables are now precomputed and mpg123_init() has
> nothing to do anymore. The main reason for this is to make usage of the
> library easier in multithreaded contexts where it is not necessarily
> easy to insert a call to something like mpg123_init() which, at least
> in theory, wants to run non-concurrently.
>
> So, a lot of internal tables and their usage got moved around. It would
> be nice if I could get a heads-up from the various platforms mpg123
> supports. So far, I got a boring x86-64 Linux system and checked if the
> compliance still works and if the performance is off. What about proper 32
> bit
> x86 machines, what about 3DNow, AltiVec? It would be nice to know that
> I didn't break something in our forest of platform and hardware ifdefs.
>
> So, please, fetch a current https://mpg123.org/snapshot and reply with
> your results!
>
> Just building mpg123 and listening to some music would be fine. Bonus
> points for running the compliance tests using the procedure below.
>
> 	wget -O test.tar.gz https://scm.orgis.org/view/mpg123/test/?view=tar
> 	tar -xf test.tar.gz
> 	cd test
> 	make
> 	perl compliance.pl /path/to/mpg123
>
> I hope this can become a new release soon-ish.
>
>
> Alrighty then,
>
> Thomas
>
>
> _______________________________________________
> mpg123-users mailing list
> mpg...@li...
> https://lists.sourceforge.net/lists/listinfo/mpg123-users
>


-- 
-------------
Education is contagious.

[mpg123-users] A round of testing of upcoming mpg123 1.27.0, please.

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

Hi folks,

There are some core changes in libmpg123 scheduld for the next feature
release. Following work by Taihei on the fixed-point decoders, all
common decoding tables are now precomputed and mpg123_init() has
nothing to do anymore. The main reason for this is to make usage of the
library easier in multithreaded contexts where it is not necessarily
easy to insert a call to something like mpg123_init() which, at least
in theory, wants to run non-concurrently.

So, a lot of internal tables and their usage got moved around. It would
be nice if I could get a heads-up from the various platforms mpg123
supports. So far, I got a boring x86-64 Linux system and checked if the
compliance still works and if the performance is off. What about proper 32 bit
x86 machines, what about 3DNow, AltiVec? It would be nice to know that
I didn't break something in our forest of platform and hardware ifdefs.

So, please, fetch a current https://mpg123.org/snapshot and reply with
your results!

Just building mpg123 and listening to some music would be fine. Bonus
points for running the compliance tests using the procedure below.

	wget -O test.tar.gz https://scm.orgis.org/view/mpg123/test/?view=tar
	tar -xf test.tar.gz
	cd test
	make
	perl compliance.pl /path/to/mpg123

I hope this can become a new release soon-ish.


Alrighty then,

Thomas

[mpg123-users] mpg123 1.26.5 relased

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

Dear mpg123 folks,

version 1.26.5 arrived:

1.26.5
------
- Add ./configure --enable-xdebug (for the resampler issue).
- Avoid denormals in the resampler by adding an alternating offset
  (helps performance without -ffast-math, depending on platform).
- libmpg123:
-- Fix ID3v2 APIC parsing when frame length bit is set (bug 306).
-- Also handle the group flag (skip the group byte).
-- Also fix up frame flag handling for ID3v2.3. Did not crop up yet,
   but it was just wrong. Impact was not detecting and bailing out on
   compressed or encrypted frames properly.


Alrighty then,

Thomas

Re: [mpg123-users] mpg123_read() (Error reading the stream. (code 18))

[Leonard B. <leo...@gm...>]

Thanks!

> On 26/02/2021, at 10:02 PM, Thomas Orgis <tho...@or...> wrote:
> 
> Am Fri, 26 Feb 2021 21:34:31 +1300
> schrieb Leonard Bocock <leo...@gm...>: 
> 
>> (1) The use of fread()
> 
> I didn't follow quite what was the issue here, but I am joyous that you
> worked it out!
> 
>> (2) The small buffer size from mpg123_outblock(mh) which is
>> inadequate for ALSA (a small buffer causes ALSA to play with jitter)
> 
> I don't quite understand this. You configure the buffers ALSA uses,
> independent of the chunks to write. See
> 
> 	http://scm.orgis.org/view/mpg123/trunk/src/libout123/modules/alsa.c?view=markup
> ,
> which you could use via libout123, too. In essence:
> 
> 34            #define BUFFER_LENGTH (ao->device_buffer > 0. ? ao->device_buffer : 0.2)
> 116            buffer_size = rate * BUFFER_LENGTH;
> 117 	        if (snd_pcm_hw_params_set_buffer_size_near(pcm, hw, &buffer_size) < 0) {
> 118 	                if(!AOQUIET) error("initialize_device(): cannot set buffer size");
> 119 	                return -1;
> 120 	        }
> 121 	        debug1("buffer_size=%lu", (unsigned long)buffer_size);
> 122 	        period_size = buffer_size / 3; /* 3 periods is so much more common. */
> 123 	        if (snd_pcm_hw_params_set_period_size_near(pcm, hw, &period_size, NULL) < 0) {
> 124 	                if(!AOQUIET) error("initialize_device(): cannot set period size");
> 125 	                return -1;
> 126 	        }
> 127 	        debug1("period_size=%lu", (unsigned long)period_size);
> 128 	        if (snd_pcm_hw_params(pcm, hw) < 0) {
> 129 	                if(!AOQUIET) error("initialize_device(): cannot set hw params");
> 130 	                return -1;
> 131 	        }
> 132 	
> 
> Important was that one, which I only realized quite recently:
> 
> 138 	        /* Start playing once we got at least full period ... this is not default? */
> 139 	        if (snd_pcm_sw_params_set_start_threshold(pcm, sw, buffer_size/2) < 0) {
> 140 	                if(!AOQUIET) error("initialize_device(): cannot set start threshold");
> 141 	                return -1;
> 142 	        }
> 
> And then the writing with whatever chunk size:
> 
> 230             frames = snd_pcm_bytes_to_frames(pcm, bytes);
> 231 	        while
> 232 	        ( /* Try to write, recover if error, try again if recovery successful. */
> 233 	                (written = snd_pcm_writei(pcm, buf, frames)) < 0
> 234 	                && snd_pcm_recover(pcm, (int)written, 0) == 0
> 235 	        )
> 236 	        {
> 237 	                debug2("recovered from alsa issue %i while trying to write %lu frames", (int)written, (unsigned long)frames);
> 238 	        }
> 
> 
> Of course, you could also do it like
> 
> 	http://scm.orgis.org/view/mpg123/trunk/doc/examples/mpg123_to_out123.c?view=markup
> 
> and let out123 do the ALSA dance, but it's your pick;-)
> 
> 
> Alrighty then,
> 
> Thomas
> 
> 
> _______________________________________________
> mpg123-users mailing list
> mpg...@li...
> https://lists.sourceforge.net/lists/listinfo/mpg123-users

Leonard Bocock
leo...@gm...

Re: [mpg123-users] mpg123_read() (Error reading the stream. (code 18))

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

Am Fri, 26 Feb 2021 21:34:31 +1300
schrieb Leonard Bocock <leo...@gm...>: 

> (1) The use of fread()

I didn't follow quite what was the issue here, but I am joyous that you
worked it out!

> (2) The small buffer size from mpg123_outblock(mh) which is
> inadequate for ALSA (a small buffer causes ALSA to play with jitter)

I don't quite understand this. You configure the buffers ALSA uses,
independent of the chunks to write. See

	http://scm.orgis.org/view/mpg123/trunk/src/libout123/modules/alsa.c?view=markup
,
which you could use via libout123, too. In essence:

 34            #define BUFFER_LENGTH (ao->device_buffer > 0. ? ao->device_buffer : 0.2)
116            buffer_size = rate * BUFFER_LENGTH;
117 	        if (snd_pcm_hw_params_set_buffer_size_near(pcm, hw, &buffer_size) < 0) {
118 	                if(!AOQUIET) error("initialize_device(): cannot set buffer size");
119 	                return -1;
120 	        }
121 	        debug1("buffer_size=%lu", (unsigned long)buffer_size);
122 	        period_size = buffer_size / 3; /* 3 periods is so much more common. */
123 	        if (snd_pcm_hw_params_set_period_size_near(pcm, hw, &period_size, NULL) < 0) {
124 	                if(!AOQUIET) error("initialize_device(): cannot set period size");
125 	                return -1;
126 	        }
127 	        debug1("period_size=%lu", (unsigned long)period_size);
128 	        if (snd_pcm_hw_params(pcm, hw) < 0) {
129 	                if(!AOQUIET) error("initialize_device(): cannot set hw params");
130 	                return -1;
131 	        }
132 	

Important was that one, which I only realized quite recently:

138 	        /* Start playing once we got at least full period ... this is not default? */
139 	        if (snd_pcm_sw_params_set_start_threshold(pcm, sw, buffer_size/2) < 0) {
140 	                if(!AOQUIET) error("initialize_device(): cannot set start threshold");
141 	                return -1;
142 	        }

And then the writing with whatever chunk size:

230             frames = snd_pcm_bytes_to_frames(pcm, bytes);
231 	        while
232 	        ( /* Try to write, recover if error, try again if recovery successful. */
233 	                (written = snd_pcm_writei(pcm, buf, frames)) < 0
234 	                && snd_pcm_recover(pcm, (int)written, 0) == 0
235 	        )
236 	        {
237 	                debug2("recovered from alsa issue %i while trying to write %lu frames", (int)written, (unsigned long)frames);
238 	        }


Of course, you could also do it like

	http://scm.orgis.org/view/mpg123/trunk/doc/examples/mpg123_to_out123.c?view=markup

and let out123 do the ALSA dance, but it's your pick;-)


Alrighty then,

Thomas

Re: [mpg123-users] mpg123_read() (Error reading the stream. (code 18))

[Leonard B. <leo...@gm...>]

Hi Martin

Found the issues. 

(1) The use of fread()
(2) The small buffer size from mpg123_outblock(mh) which is inadequate for ALSA (a small buffer causes ALSA to play with jitter)

To resolve (1) I have changed the code to that used in the example file “mpg123_to_wav_replaced_io.c". This uses read() in a callback arrangement instead of fread(). I haven’t tested if the callback is actually necessary, but I think not.. I assume the issue with fread() is something to do with the internal buffering it does.

To resolve (2) I have used a much larger write buffer than read buffer, like this……

    int samples = 0;    
    int scale = 16;         // Set this high enough to satisfy ALSA

    buffer_size = mpg123_outblock(mh);
    unsigned char *buffer = malloc(buffer_size);

    do {
        struct sa_audio_data_mp3_t *audio = (struct sa_audio_data_mp3_t*) malloc(sizeof (struct sa_audio_data_mp3_t));
        buffer_write_size = buffer_size * scale;
        audio->data = malloc(buffer_write_size);
        audio->data_len_bytes = 0; 

        for (int idx = 0; idx < scale; idx++) {				// Stack the in data into the out buffer by scale number of times
            err = mpg123_read(mh, buffer, buffer_size, &size);
            if (err < 0 )
                printf("Error reading (%s)\n", mpg123_strerror(mh));
            memcpy(&audio->data[audio->data_len_bytes], buffer, size);
            audio->data_len_bytes = audio->data_len_bytes + size;
        }

        audio->play_metadata = play_metadata;
        audio->chunk_count = chunk_count++;
        if (!play_queue_push(audio))
            free(audio);
        samples += size / sizeof (short);

    } while (err == MPG123_OK);

Thanks very much, nice to have it working.
Leonard


> On 23/02/2021, at 1:21 AM, Martin Guy <mar...@gm...> wrote:
> 
> On 22/02/2021, Leonard Bocock <leo...@gm... <mailto:leo...@gm...>> wrote:
>> Hi list
>> 
>> I’m stumped. This is what I see in the trace log.
>> 
>>>> in=294912 read=73728 decoded=73728 chunk=17
>>>> in=294912 read=73728 decoded=73728 chunk=18
>>>> mpg123_read() error (Error reading the stream. (code 18))
>>>> in=294912 read=73728 decoded=32256 chunk=19
>>>> fread() from file
>>>> mpg123_feed() fill mpg123 buffer
>>>> in=368640 read=73728 decoded=73728 chunk=20
>>>> in=368640 read=73728 decoded=73728 chunk=21
>>>> in=368640 read=73728 decoded=73728 chunk=22
>>>> in=368640 read=73728 decoded=73728 chunk=23
>>>> mpg123_read() error (Error reading the stream. (code 18))
>>>> in=368640 read=73728 decoded=27648 chunk=24
>> 
>> Notice the last chunk returned from mpg123_read() is truncating by a value
>> of either 27648 or 32256 with error code 18. I swapped the coding approach
>> to use mpg123_decode() but am seeing the same issue.
>> 
>> The core of the C code w/o error handling is here.
> 
> Hi Leonard
>   If you can attach the MP3 file in question or make it available
> some other way, I'll see if my use of libmpg123 reads it OK. For your
> C code, a whole example C file would be easier to debug. The only
> thing that comes to mind from a quick inspection is that mh doesn't
> know the FORMAT when mpg123_outblock is called, but I doubt it's that
> or it wouldn't work at all.
>   Lastly, to see if it's libmpg123 that's unable to read the MP3
> file, or your use of libmpg123 that needs tweaking, you could see if
> the mpg123 command reads the file OK.
> 
>    M

Leonard Bocock
leo...@gm...

Re: [mpg123-users] mpg123_read() (Error reading the stream. (code 18))

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

On 22/02/2021, Leonard Bocock <leo...@gm...> wrote:
> Hi list
>
> I’m stumped. This is what I see in the trace log.
>
>>> in=294912 read=73728 decoded=73728 chunk=17
>>> in=294912 read=73728 decoded=73728 chunk=18
>>> mpg123_read() error (Error reading the stream. (code 18))
>>> in=294912 read=73728 decoded=32256 chunk=19
>>> fread() from file
>>> mpg123_feed() fill mpg123 buffer
>>> in=368640 read=73728 decoded=73728 chunk=20
>>> in=368640 read=73728 decoded=73728 chunk=21
>>> in=368640 read=73728 decoded=73728 chunk=22
>>> in=368640 read=73728 decoded=73728 chunk=23
>>> mpg123_read() error (Error reading the stream. (code 18))
>>> in=368640 read=73728 decoded=27648 chunk=24
>
> Notice the last chunk returned from mpg123_read() is truncating by a value
> of either 27648 or 32256 with error code 18. I swapped the coding approach
> to use mpg123_decode() but am seeing the same issue.
>
> The core of the C code w/o error handling is here.

Hi Leonard
   If you can attach the MP3 file in question or make it available
some other way, I'll see if my use of libmpg123 reads it OK. For your
C code, a whole example C file would be easier to debug. The only
thing that comes to mind from a quick inspection is that mh doesn't
know the FORMAT when mpg123_outblock is called, but I doubt it's that
or it wouldn't work at all.
   Lastly, to see if it's libmpg123 that's unable to read the MP3
file, or your use of libmpg123 that needs tweaking, you could see if
the mpg123 command reads the file OK.

    M

[mpg123-users] mpg123_read() (Error reading the stream. (code 18))

[Leonard B. <leo...@gm...>]

Hi list

I’m stumped. This is what I see in the trace log.

>> in=294912 read=73728 decoded=73728 chunk=17
>> in=294912 read=73728 decoded=73728 chunk=18
>> mpg123_read() error (Error reading the stream. (code 18))
>> in=294912 read=73728 decoded=32256 chunk=19
>> fread() from file
>> mpg123_feed() fill mpg123 buffer
>> in=368640 read=73728 decoded=73728 chunk=20
>> in=368640 read=73728 decoded=73728 chunk=21
>> in=368640 read=73728 decoded=73728 chunk=22
>> in=368640 read=73728 decoded=73728 chunk=23
>> mpg123_read() error (Error reading the stream. (code 18))
>> in=368640 read=73728 decoded=27648 chunk=24

Notice the last chunk returned from mpg123_read() is truncating by a value of either 27648 or 32256 with error code 18. I swapped the coding approach to use mpg123_decode() but am seeing the same issue.

I’m clearly missing something basic here, but have no idea what !!!	

The core of the C code w/o error handling is here. 

    buffer_read_size = mpg123_outblock(mh);
    buffer_write_size = mpg123_outblock(mh) * 2;

    while (1) {

        printf("fread() from file\n");
        bytes_read = fread(buffer_read, sizeof(unsigned char), buffer_read_size, fp);

        in += bytes_read;
        printf("mpg123_feed() buffer\n");
        rv = mpg123_feed(mh, buffer_read, bytes_read);
      
        outc += size;
        
        while (rv != MPG123_ERR && rv != MPG123_NEED_MORE) {
            
            struct sa_audio_data_mp3_t *audio = (struct sa_audio_data_mp3_t*) malloc(sizeof (struct sa_audio_data_mp3_t));
            audio->data = malloc(buffer_write_size * sizeof(short) * 2);
            rv = mpg123_read(mh, audio->data, bytes_read, &size);

            if (rv == MPG123_NEW_FORMAT) {
                mpg123_getformat(mh, &src_samplerate, &src_channels, &src_format);
                fprintf(stdout, "Old format: %li Hz, %i channels, encoding value 0x%x\n", src_samplerate, src_channels, src_format);
                play_metadata = sa_alsa_open(src_channels, src_samplerate, get_bit_depth(src_format), SA_LIBMPG123)) == NULL);
                mpg123_format_none(mh);
                mpg123_format(mh, src_samplerate, src_channels, src_format)), rv < MPG123_OK);
            }
            // Push audio data to FIFO queue for playing
            audio->data_len_bytes = size;
            audio->play_metadata = play_metadata;
            audio->chunk_count = chunk_count++;
            if (! play_queue_push(audio))
                free(audio);
            outc += size;
            printf("in=%lu read=%lu decoded=%lu chunk=%d\n", in, bytes_read, size, audio->chunk_count);

        }
        if (rv == MPG123_ERR) {
            printf("Some error: %s", mpg123_strerror(mh));
            break;
        }
    }  

Thanks, 

Leonard Bocock
leo...@gm...

Re: [mpg123-users] Question about mpg123 playlists

[Alan C. <ala...@gm...>]

OK, just uploaded today: https://cgi-jukebox.sourceforge.io/  Meant
for users on a small (wifi?) LAN to play music through a common shared
server & stereo.  Usable from phones, tablets, computers.  So it sort
of becomes an mpg123 frontend but with limited features.

On 12/30/20, Thomas Orgis <tho...@or...> wrote:
> Am Wed, 30 Dec 2020 12:48:58 -0500
> schrieb Alan Corey <ala...@gm...>:
>
>> The quote thing is interesting, and using the newline.  Debian
>> starting with Buster (current) has started putting single quotes in ls
>> listings for filenames with spaces, I don't really like it.
>
> It only does it when writing to the terminal. `ls | cat` has no quotes.
>
>
> Alrighty then,
>
> Thomas
>


-- 
-------------
Education is contagious.

Re: [mpg123-users] Question about mpg123 playlists

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

Am Wed, 30 Dec 2020 12:48:58 -0500
schrieb Alan Corey <ala...@gm...>: 

> The quote thing is interesting, and using the newline.  Debian
> starting with Buster (current) has started putting single quotes in ls
> listings for filenames with spaces, I don't really like it.

It only does it when writing to the terminal. `ls | cat` has no quotes.


Alrighty then,

Thomas

Re: [mpg123-users] Question about mpg123 playlists

[Alan C. <ala...@gm...>]

OK, I did a chown -R www-data on my mp3 directory.  Took the quotes
out of the printf that was adding them.  And it works.

I expect to put it on Sourceforge within a week.  It scans a directory
structure of mp3s, subdirectories get recursed into, mp3s get linked.
No HTML forrns, the mp3 links pass a file number to  my CGI program.
There's a "play all" link in each subdir's page that feeds a starting
file number and count to the CGI which is what I just fixed.  So over
wifi you can play songs on the server over a phone even.  I have some
cleanup to do but it's working.

The quote thing is interesting, and using the newline.  Debian
starting with Buster (current) has started putting single quotes in ls
listings for filenames with spaces, I don't really like it.


On 12/30/20, Thomas Orgis <tho...@or...> wrote:
> Am Wed, 30 Dec 2020 11:40:45 -0500
> schrieb Alan Corey <ala...@gm...>:
>
>> Seems like if
>> mpg123 does the looping and tries to open the files it's as a
>> different user?
>
> It is trying to open files/URLs as specified, as the user it is started
> as. HTTP requests are of course fulfilled by the web server …
>
>> Yes, I'm including the quotes.  It's Linux and I didn't choose the
>> filenames so there are spaces in most.
>
> No quotes, please.
>
> #M3U
> file1.mp3
> file 2 with lots of spaces and good ol' fun.mp3
>
>
> The line break as separator is what is not allowed to appear in a name.
>
>
>> It seems like you can make workable m3u files by just ls *.mp3 >
>> file.m3u.
>
> Indeed.
>
>
> Alrighty then,
>
> Thomas
>


-- 
-------------
Education is contagious.

Re: [mpg123-users] Question about mpg123 playlists

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

Am Wed, 30 Dec 2020 11:40:45 -0500
schrieb Alan Corey <ala...@gm...>: 

> Seems like if
> mpg123 does the looping and tries to open the files it's as a
> different user?

It is trying to open files/URLs as specified, as the user it is started
as. HTTP requests are of course fulfilled by the web server …

> Yes, I'm including the quotes.  It's Linux and I didn't choose the
> filenames so there are spaces in most.

No quotes, please.

#M3U
file1.mp3
file 2 with lots of spaces and good ol' fun.mp3


The line break as separator is what is not allowed to appear in a name.


> It seems like you can make workable m3u files by just ls *.mp3 > file.m3u.

Indeed.


Alrighty then,

Thomas

Re: [mpg123-users] Question about mpg123 playlists

[Alan C. <ala...@gm...>]

There's a more complicated explanation.  When I just looked in my
Apache error log I saw a bunch of file access errors from trying to
run a playlist.  Yet I can play the files individually.  Seems like if
mpg123 does the looping and tries to open the files it's as a
different user?  I'll try loosening up the file permissions.  I'm
logged in as root, Apache runs as the www-data user account.

Yes, I'm including the quotes.  It's Linux and I didn't choose the
filenames so there are spaces in most.

It seems like you can make workable m3u files by just ls *.mp3 > file.m3u.

On 12/30/20, Thomas Orgis <tho...@or...> wrote:
> Am Wed, 30 Dec 2020 10:50:50 -0500
> schrieb Alan Corey <ala...@gm...>:
>
>> What I don't see mentioned anywhere is much mention of the exact
>> format.
> [of mpg123 playlists]
>
>
>> /usr/bin/mpg123 --output alsa -d plughw:1,0,0 -@ -
>> "/data/mp3/Uriah_Heep/1972 - Demons And Wizards/01 - The Wizard.mp3"
>
> Are you actually including the quotes?
>
>
> Generally, we did not think much about documenting any special playlist
> format. As well as with MPEG audio streams, mpg123 tries to deal with
> what is out there, classic M3U and also PLS files. Mpg123 didn't get to
> choose anything … the stuff was just out there.
>
> The most simple format is indeed just the file names separated by
> newlines. You could avoid mpg123 guessing around by starting with #M3U
> on the first line:
>
> #M3U
> filename1.mp3
> filename2.mp3
> filename3.mp3
>
>
> Alrighty then,
>
> Thomas
>
>
> _______________________________________________
> mpg123-users mailing list
> mpg...@li...
> https://lists.sourceforge.net/lists/listinfo/mpg123-users
>


-- 
-------------
Education is contagious.

Re: [mpg123-users] Question about mpg123 playlists

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

Am Wed, 30 Dec 2020 10:50:50 -0500
schrieb Alan Corey <ala...@gm...>: 

> What I don't see mentioned anywhere is much mention of the exact
> format.
[of mpg123 playlists]


> /usr/bin/mpg123 --output alsa -d plughw:1,0,0 -@ -
> "/data/mp3/Uriah_Heep/1972 - Demons And Wizards/01 - The Wizard.mp3"

Are you actually including the quotes?


Generally, we did not think much about documenting any special playlist
format. As well as with MPEG audio streams, mpg123 tries to deal with
what is out there, classic M3U and also PLS files. Mpg123 didn't get to
choose anything … the stuff was just out there.

The most simple format is indeed just the file names separated by
newlines. You could avoid mpg123 guessing around by starting with #M3U
on the first line:

#M3U
filename1.mp3
filename2.mp3
filename3.mp3


Alrighty then,

Thomas

[mpg123-users] Question about mpg123 playlists

[Alan C. <ala...@gm...>]

What I don't see mentioned anywhere is much mention of the exact
format.  I'm trying to feed mpg123 from a popen() call from a CGI
program.  I could put newlines between files or spaces, so I tried
both.  I feed the top line below in my original popen, then in a loop
write the filename lines to the open pipe and do a pclose().  I can
play individual files with a different part of the same CGI.  Using
mpg123 from Debian Bullseye debs so 1.26.3-1

  Alan

/usr/bin/mpg123 --output alsa -d plughw:1,0,0 -@ -
"/data/mp3/Uriah_Heep/1972 - Demons And Wizards/01 - The Wizard.mp3"
"/data/mp3/Uriah_Heep/1972 - Demons And Wizards/02 - Traveller In Time.mp3"
"/data/mp3/Uriah_Heep/1972 - Demons And Wizards/03 - Easy Livin'.mp3"
"/data/mp3/Uriah_Heep/1972 - Demons And Wizards/04 - Poet's Justice.mp3"
"/data/mp3/Uriah_Heep/1972 - Demons And Wizards/05 - Circle Of Hands.mp3"
"/data/mp3/Uriah_Heep/1972 - Demons And Wizards/06 - Rainbow Demon.mp3"
"/data/mp3/Uriah_Heep/1972 - Demons And Wizards/07 - All My Life.mp3"
"/data/mp3/Uriah_Heep/1972 - Demons And Wizards/08 - Paradise.mp3"
"/data/mp3/Uriah_Heep/1972 - Demons And Wizards/09 - The Spell.mp3"
"/data/mp3/Uriah_Heep/1972 - Demons And Wizards/10 - Why (Previously
Unreleased Extended Version).mp3"
"/data/mp3/Uriah_Heep/1972 - Demons And Wizards/11 - Rainbow Demon
(Previously Unreleased Single Edit).mp3"
"/data/mp3/Uriah_Heep/1972 - Demons And Wizards/12 - Proud Words On A
Dusty Shelf (Out-Take).mp3"
"/data/mp3/Uriah_Heep/1972 - Demons And Wizards/13 - Home Again To You
(Demo - Previously Unreleased Version).mp3"
"/data/mp3/Uriah_Heep/1972 - Demons And Wizards/14 - Green Eye (Demo -
Previously Unreleased).mp3"

-- 
-------------
Education is contagious.

[mpg123-users] mpg123 1.26.4 released

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

Dear mpg123 folks,

as this weird year draws to an end, I present to you a rather mundane
mpg123 release. It's mainly build fixes people contributed for the
cmake port, but also this long-standing issue about theoretically bad
trigonometry.

1.26.4
------
- Clarify seeking documentation regarding samples and PCM frames.
- Fix build on MorphOS (patch by Ozkan Sezer, bug 295).
- Fix cmake build to install fmt123.h.
- Some cmake build fixes, tinyalsa addition by Maarten (bug 299).
- libmpg123: explicitly handle some irrelevant corner cases in tabinit
  (bug 279)

It's available at the usual places.


I wish you all a good start into the new year, which has a good chance
to being a better one for most of us than the one that is ending now.


Alrighty then,

Thomass

Re: [mpg123-users] How to know whether the file length is in the ID tags

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

On 23/08/2020, Thomas Orgis <tho...@or...> wrote:
> Am Sat, 22 Aug 2020 23:19:55 +0200 schrieb Martin Guy <mar...@gm...>:
>
>>    In the docs I see mpg123_open_fixed() which would
>>         "call mpg123_scan() if there is no header frame to tell the
>> track length."
>> which sounds like a better option, but in the version of libmpg123
>> that I have (Debian stable), mpg123_open_fixed is not defined in
>> mpg123.h or in the library.
>
> … it entered mpg123 with 1.26.0.

Ah, yes, Debian is always several years behind, but I'm going for
portable so the less modern features I use the better. It's also
missing format2(), which I needed to be able to set the encoding of
returned samples without forcing it to do sample rate conversion, but
got round that by calling getformat() first and repeating the returned
sample rate to format()

>>    So my question is, how can I know whether the length is correct
>> (not an estimate) from an ID tag, so that I can know whether I can
>> avoid calling mpg123_scan() for most files?
>
> There's no direct query for that. But you got two good guesses to
> identify hopefully most relevant files.
>
> 1. Call mpg123_info() and check for the vbr mode.
>
> If it's not MPG123_CBR, you had some Xing/Lame/Info frame to tell the
> decoder that. Track length is a common feature that all these frames have.
>
> 2. Call mpg123_getstate() for MPG123_ENC_DELAY and/or MPG123_ENC_PADDING.
>
> If one of them is != -1, you got a Lame info tag that contained such a
> value, also implying that there is proper length info.

Blimey! I'll do that then! Cheers!

   M

Re: [mpg123-users] How to know whether the file length is in the ID tags

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

Am Sat, 22 Aug 2020 23:19:55 +0200
schrieb Martin Guy <mar...@gm...>: 

>    In the docs I see mpg123_open_fixed() which would
>         "call mpg123_scan() if there is no header frame to tell the
> track length."
> which sounds like a better option, but in the version of libmpg123
> that I have (Debian stable), mpg123_open_fixed is not defined in
> mpg123.h or in the library.

… it entered mpg123 with 1.26.0.

>    So my question is, how can I know whether the length is correct
> (not an estimate) from an ID tag, so that I can know whether I can
> avoid calling mpg123_scan() for most files?

There's no direct query for that. But you got two good guesses to
identify hopefully most relevant files.

1. Call mpg123_info() and check for the vbr mode.

If it's not MPG123_CBR, you had some Xing/Lame/Info frame to tell the
decoder that. Track length is a common feature that all these frames have.

2. Call mpg123_getstate() for MPG123_ENC_DELAY and/or MPG123_ENC_PADDING.

If one of them is != -1, you got a Lame info tag that contained such a
value, also implying that there is proper length info.

One can imagine introducing a key for mpg123_getstate() that tells you
that track length is accurately known … but then, updating libmpg123
already gives you mpg123_open_fixed(), wich would take care of the to
scan or not to scan logic.


Alrighty then,

Thomas