Darrick Servis wrote:
> I'm curious what plans there are for improving the aflibMpgFile module. I've
> been playing around with it and added the ability to seek to a sample within
> the Mpeg file. I also rewrote the open routine so you get the total_sample
> length. It works well but It's kind of goofy. It doesn't work well when you
> do a lot of seeks. Currently I'm taking advantage of mpg123 ability to skip
> frames and just reopening the pipe when the position changes from the last
> read. This is quite slow though.
>
> However, I got some mpeg file specs and was planning on opening the mpeg file
> with fopen and then opening a pipe to mpg123. Then seek to what frame I need
> in the mpeg file and running that through the pipe.
The problem with mpg format is that it is compressed and a streaming
format. Thus
you can't seek to a particular spot in the file. You can get close but
not
exactly. Hopefully Vorbis, a patent free compressed format, will solve
this. It
supposedly will solve this. I was very impressed with an article of this
in the
latest Linux Journal. I would be happy to include any changes you have
made.
I think getting seek ability and total size even if they are approximate
would
be an improvement. The only problem would be if you borrowed any code
from
any other program to do these changes. For instance last time I checked
mpg123
it was GPL. This module currently is LGPL. If we wanted to keep the
module LGPL
then we can't use code from a GPL program.
>
> Also regarding magic and AFLIB_AUTO_TYPE. I think magic works well. If a
> programmer wants to use a file type which can't be determined by magic then
> I'm sure they don't want to use be able to auto detect as there is usually
> other things which need to be done to handle the file.
>
> However, concerning all the aflibAudioType enums. I think as opposed to this
> the module file should generate the list of supported audio types. So rather
> then:
>
> static aflibFile *
> open(
> aflibFileType type_enum,
> const string& file, aflibConfig* cfg = NULL, aflibStatus* status = NULL);
>
> you'd have:
>
> static aflibFile *
> open(
> const string& audio_type,
> const string& file, aflibConfig* cfg = NULL, aflibStatus* status = NULL);
I think this is a good idea. Let me give it some though and I might
include
this.
>
> And for writing you should be able to open the file based on extension. That
> way you could save files similiar to how the gimp saves files. Also the
> programmer won't have to worry about adding new types.
The only problem with this is that there are numerous subtypes within a
file
format. Such as WAV which can have mu-law, a-law, or PCM. I don't know
of a
way to handle file unique information cleanly. The way I choose is to
create
a new file type for each one. Such as a unique type for each output bit
rate
MP3 format. I would hate for application programmers have to have all
kinds
of unique code to handle each format. Do you have any ideas on how to
handle
subfile information?
Bruce Forsberg
|
