lib/mpg123
1
0
Fork 0
mirror of http://mpg123.de/trunk/.git synced 2025-10-29 14:09:21 +03:00
Code Activity

TODO for the future

Browse Source 
git-svn-id: svn://scm.orgis.org/mpg123/trunk@4628 35dc7657-300d-0410-a2e5-dc2837fedb53
This commit is contained in:
thor
2020-04-05 22:48:02 +00:00
parent e8178d7ad1
commit 266017300e
2 changed files with 12 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
NEWS
View File

@@ -2,9 +2,6 @@
------
TODO: Figure out terminal printout encoding for Windows.
TODO: Make libout123 and/or mpg123 use that to convert on the fly. Optionally?
A new incompatible version of libmpg123 would drop duplicate code for
conversions …
- Starting to intentionally use C99 in the codebase. API headers are still
supposed to be compatible to C89.

14
TODO
View File

@@ -22,8 +22,18 @@ Program terminated with signal 11, Segmentation fault.
1. mpg123 could pick up new sample rates suggested by the output modules (like a jack server fixed to 96kHz) and adapt to that.
Though the practical rates for MPEG audio are up to 48kHz ... but one could easily upsample.
Currently, we detect standard rates and resample when needed... but not new ones.
Also, the libsyn123 resampler should be employed. Just generally, libsyn123
could also provide encoding conversions for formats not directly supported
by accelerated decoders. See out123, which is the
2. What's about SINGLE_MIX?
Check what is _really_ happening there, make some test file...
3. Add playback of WAV files in mpg123 and out123.
Parsing the standard 44-byte header really is no big issue. WAV64 is
not really a thing, is it? Anyway, mpg123/out123 will probably just ignore
the length in the header. Also, both programs need a switch to enable
treating input as WAV, though out123 might get away with a default
mode of looking out for a header unless format options were given. Yes,
that makes sense. And perhaps I really should limit this to out123.