Replacing mpglib

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Replacing mpglib

Thomas Orgis
Hi,

I am in the process of adding extraction of the plotting_data/pinfo to a branch
of libmpg123. Somehow I want it all in one go: Replace mpglib for input
decoding and for the analyser. As there is a number of differences
between the codes (my and your layer3.c, namely storage of frame data),
I would like someone to nod to this:

Am I right in my idea that all I need to do is this?

1. Provide decoding to PCM samples (float and clipped s16 … although I
   wonder why Lame would need anything but unclipped float).
2. Fill in plotting_data *pinfo with the data needed for mp3x.
   → Any other funky internal data needed?
3. Use libmpg123's API for framewise decoding (there is some choice,
   I'll see what we really need …).
4. Figure out how much lame wants to know about encoder and decoder
   padding for MP3 input or if gapless data from libmpg123 is fine in
   places (it cuts away those normally).

The pinfo itself doesn't seem that problematic. Naturally, modifying
the libmpg123 code is the easier part for me.
'

Alrighty then,

Thomas
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Replacing mpglib

bouvigne
On 2017-08-02 07:45, Thomas Orgis wrote:
> Am I right in my idea that all I need to do is this?
>
[...]
> 4. Figure out how much lame wants to know about encoder and decoder
>    padding for MP3 input or if gapless data from libmpg123 is fine in
>    places (it cuts away those normally).

That looks ok to me.
Regarding point 4, there is a possibility that for the
decoding/transcoding purpose, gapless handling from libmpg123 is
sufficient (it removes both leading and trailing data, right?). A long
time ago, gapless decoding was not available in mpglib, so we had to add
a way to handle it.

You might also have to look at teh following options:
--mp1input,--mp2input,--mp3input,--decode-mp3delay
I'm not sure if they are handled through lame, or if they hae an impact
on the way we are calling the decoding lib.

Regards,

--
Gabriel Bouvigne


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Replacing mpglib

Thomas Orgis
Am Wed, 02 Aug 2017 08:35:40 +0200
schrieb [hidden email]:

> decoding/transcoding purpose, gapless handling from libmpg123 is
> sufficient (it removes both leading and trailing data, right?)

Yes it does … I presume the analyser wants to handle the padding
explicitly?

> You might also have to look at teh following options:
> --mp1input,--mp2input,--mp3input,--decode-mp3delay

Thanks. Will do.

Currently I am trying to dissect struct plotting_data into the parts
that get filled in by libmpg123 and those internal to Lame. Some glue
will be applied. Something dawned on me, though, as I did not yet
review the I/O aspect: In mp3x, is there a tight coupling between the
encoding producing a frame and then that being streamed to the decoder,
after which the next encoded frame appears? So the stream is
continuously at the end from the perspective of the decoder?


Alrighty then,

Thomas
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Replacing mpglib

Robert Hegemann
Am .08.2017, 16:09 Uhr, schrieb Thomas Orgis <[hidden email]>:

> Currently I am trying to dissect struct plotting_data into the parts
> that get filled in by libmpg123 and those internal to Lame. Some glue
> will be applied. Something dawned on me, though, as I did not yet
> review the I/O aspect: In mp3x, is there a tight coupling between the
> encoding producing a frame and then that being streamed to the decoder,
> after which the next encoded frame appears? So the stream is
> continuously at the end from the perspective of the decoder?

Yes, the frame analyzer steps frame by frame through the input data.
When analyzing an already encoded mp3 file, a frame by frame decode from
start to finish. Else every encoded mp3 frame get feeded one by one into
the decoder to show the info.


> Alrighty then,
>
> Thomas

Ciao Robert

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev