ffmpeg using lavf encoder as opposed to libmp3lame

[Karcsi Kolbasz]

I am not sure why this is the case, but when I look at a converted file, the encoder field lists lavf55.33.  However, my command I use is:

command: ffmpeg -i $source -y -acodec libmp3lame -qscale:a 0 $dest

I am telling ffmpeg to use libmp3lame, but it appears to still use lavf.  I am using a docker container from another user so I am not sure if they did not install something correctly or if this behavior is to be expected.  I was looking online and saw the libmp3lame codec should install when ffmpeg is installed, but my only guess is that it is not actually there to be used.  I was curious to see if there was a way to check for the codec and its existence as lavf appears to be the codec more for video files as opposed to audio.

[Adrian Sampson]

I think that ffmpeg might use that encoder ID for *all* files it produces, even when libmp3lame does the actual transcoding. Have you checked whether this is beets-specific or also true when you run ffmpeg manually?

--
You received this message because you are subscribed to the Google Groups "beets" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beets-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Karcsi Kolbasz]

awesome question, I will need to try it manually on a file on the host system.  If I can figure out how to do this, I will test and report

[Karcsi Kolbasz]

Adrian, I went ahead and tested this out.  I installed ffmpeg on a windows machine and ran the same command.  The resulting file was the same, except that it was lavc vs lavf, but I am not super concerned there.

I guess what I was expecting was to see lame as opposed to this lavf/c.  I have used dbpoweramp to convert in the past and that is what I was used to.  However, after poking around, I now realize that ffmpeg with libmp3lame is not the same as lame itself as used by dbpoweramp, which is fine and now makes more sense.  Though it does raise the question of if the convert plugin can use straight lame or is it strictly ffmpeg unless someone rewrites it?  I am accepting of the current functionality, but still wanted to ask if straight lame was feasible. 

On Tuesday, July 14, 2015 at 2:04:44 PM UTC-4, Adrian Sampson wrote:

[Adrian Sampson]

The plugin is happy to use any transcoder you like, as long as you can sort out how to invoke it on the command line (and configure beets accordingly).

[Karcsi Kolbasz]

which I assume then is the same as the ffmpeg command:

except using the lame syntax vs ffmpeg

or, would I need to do other special things to make lame available to beets beyond that?

[Adrian Sampson]

On Jul 16, 2015, at 9:11 AM, Karcsi Kolbasz <kolbas...@gmail.com> wrote:

or, would I need to do other special things to make lame available to beets beyond that?

No. The plugin invokes any command you tell it to, just as you would from the command line. The command doesn’t need to know anything about beets.

[Karcsi Kolbasz]

It would seem lame does not have direct support for flac and that it requires another app to pass it through, therefore, making this super complicated.  I will stick with ffmpeg and be happy.

When attempting to run standalone, lame throws and error for unsupported format.  Unless someone knows otherwise, ffmpeg it is.