In mpg321.c the difference beetween playbuf.num_frames
and current_frame overflows because current_frame
isn't reinitialized (to zero) before playing next song;
the problem is shown when multiple mp3's is given in
the command line and is turned on the -v (verbose)
switch (to view the frame counter); the problem
persists even if the -v
switch is omitted (obviously we don't see it).
For the first song the problem isn't shown because
current_frame is 0, so the difference beetwen it and
playbuf.num_frames is, of corse, correct
(playbuf.num_frames > current_frame). For the second
song current_frame isn't reinitialized so, of course,
is egual to playbuf.num_frames of the previous song;
now two cases are possible:
1. the playbuf.num_frames of the previous song (and,
so, the current_frame) is smaller than or egual to
playbuf.num_frames of the current song: the difference
is greater than or egual to zero and will overflow
later (this depends on the size of difference; it's
possible, rarely, that the previuos song is much
smaller than the current, and it not overflows now).
2. the playbuf.num_frames of the previous song is
greater than playbuf.num_frames of the current song:
overflows, restarting from "ULONG_MAX - current_frame +
playbuf.num_frames + 1" (the result of the difference that
overflows, because we expect that the result is
unsigned instead of signed).
In any case, when the current song terminate,
current_frame is the sum of the previous
playbuf.num_frames and the playbuf.num_frames of the
current song and so on (this can cause another overflow
to current_frame if your playlist is very large).
The described problem appears when typing command lines
mpg321 -v /local/songs/*.mp3
mpg321 -v /local/songs/1-st.mp3 /local/songs/2-nd.mp3
/local/songs/3-rd.mp3 ... /local/songs/n-th.mp3
The easy way to solve this problem is resetting
current_frame to zero before playing next song. I
attached a very little patch to do that.
I hope it will be usefull.