#13 --frames option not documented correctly

closed-fixed
Joe Drew
5
2002-07-14
2002-05-09
No

In version 0.2.10, the manual page claims that the
`--frames N' option asks mpg321 to "decode only the
first N frames of the stream."

But the code actually uses N as the index of the
_last_ frame to decode, not as the _number_ of frames
to decode. Thus, if one wants frames 1000 through
1099 from an MP3 file, the options to pass are
currenly these:

--skip 1000 --frames 1099

instead of the following, which are implied by the
manual page:

--skip 1000 --frames 100

The problem seems to be in function read_header()
[file mad.c], at this statement:

/* Stop playing if -n is used, and we're at the frame
specified. */
if ((playbuf->max_frames != -1) && (current_frame >
playbuf->max_frames))

Also:

- The help page displayed by mpg321 does not mention
--frames.

- This help page is displayed on stderr instead of
stdout, which is inconvenient when one wants to write
`mpg321 | less'. The GNU Coding Standard recommends
using stdout:

http://www.gnu.org/prep/standards.html#SEC18

Discussion

  • Joe Drew

    Joe Drew - 2002-05-09

    Logged In: YES
    user_id=330927

    The stderr issue is officially Not My Fault; talk to the
    author of mpg123 as to why he uses stderr. I have to ensure
    compatibility.

    I'll investigate the rest of this bug wrt what mpg123 does
    and update either the code or documentation. Thanks for the
    report!

     
  • Joe Drew

    Joe Drew - 2002-07-14

    Logged In: YES
    user_id=330927

    You're right, and this has been fixed in CVS.

    As for stderr vs stdout: it's not my choice. mpg123 uses
    stderr, and I need to conform to it, unfortunately.

     
  • Joe Drew

    Joe Drew - 2002-07-14
    • status: open --> closed-fixed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks