[FFmpeg-user] Question regarding encoding a file

[Zak]

On 2018-06-02 at 4:47 AM EDT, Paweł Więch wrote:
> Hello guys.
>
> Im having huge difficulties with a decoding file/batch decoding 
> multiple files at once from source audio file which is a WAV file to 
> an mp3 lossy format. I want to do a very specific thing.
>
> Is it possible with ffmpeg libraries to encode WAV file to MP3 320cbr 
> stereo or joiint stereo with build in libmp3lame/lavfformat? Every 
> time output file is encoded using lavc instead lavf.
>
> Somehow it must be possible because google play store encodes that way 
> i supose.
>
> Please have a look at the file i have attached. Tool: lavf | This is 
> what foobar2000 says.

foobar2000 is a notoriously bad way to read the metadata from MP3 files. 
I will immediately start by suggesting two alternatives that are far 
better, less ambiguous, and are both Free Software:

Mutagen
Works with MP3s, M4As (AAC audio compression algorithm, generally), 
Ogg/Vorbis, FLAC, WAV, and many formats.

https://mutagen.readthedocs.io/en/latest/

eyeD3
Works with MP3 files only, far more powerful than Mutagen. Harder to 
learn initially.

http://eyed3.readthedocs.io/en/latest/

Notice that foobar2000 is proprietary software (not Free Software, i.e 
foobar2000 is freedom-denying software), so you don't have the freedom 
to look at the source code, see what it is doing, or fix what it is 
doing. It was almost more popular and more actively developed about 10 
years ago, so many problems that emerged more recently have not been 
addressed at all. foobar2000 must be understood using deduction and 
black box analysis, and cannot be fixed.

Here are some specific clues that foobar2000 is misbehaving on your MP3 
in your screenshot:

1. The fact that it says "tool" is troubling and ambiguous. It is 
entirely unclear where that came from. The term "encoder" would be a bit 
less ambiguous, unless it is being misused. The term "encoder", if used 
correctly, should give the string in the TSSE frame of an ID3v2 tag. 
foobar2000 sometimes populates the "encoder" metadata using the LAME 
Info Tag, but it does this incorrectly because the code to do so has not 
been updated since prior to 2012. Specifically, foobar2000 reads until 
it sees a lowercase ASCII letter, it includes that letter, and then 
stops. In fact, it should stop after exactly 9 bytes no matter what, 
because this is a fixed-width field that doesn't necessarily end in a 
lowercase letter. (Note: This behavior is quite likely different in 
different versions of foobar2000, I have no idea, I determined this 
through black box analysis of just one version. There is no changelog 
saying when they may have fixed or changed this bug, and the source code 
is secret and cannot be searched.)

2. The "tool" value of "Lavf" cannot have come from the LAME Info Tag, 
it is too short and in practice the LAME Info Tag is either absent or 
the encoder field starts with the four uppercase letters "LAME".

3. The "tool" value of "Lavf" may have come from searching for ASCII 
strings toward the top of the MP3 file, especially inside padding 
characters. Information in this part of the file is fairly durable even 
if the ID3 tags are repeatedly deleted and re-created. This is most 
likely what foobar2000 is doing. This is most likely where "Lavf" came from.

4. In theory, the "tool" value may have come from the filesystem. It may 
not even be in the MP3 file itself. foobar2000 uses the Windows 
filesystem API heavily to read the mtime and size, but also other 
things. I think this is unlikely to be happening with the string "Lavf".

5. The screenshot says it has an ID3v1 tag, which will never have the 
TSSE frame and will thus never say the encoding tool. The only thing we 
know for sure is that the "tool" value came from the wrong place. Also, 
it clearly does have an ID3v1 tag because of the date, the genre (it is 
one of the one-byte WinAmp genres), and the "? - ?" because the artist 
and song name are blank in the ID3v1 tag, and it has used the filename 
with the ".mp3" stripped off the end. The file may have both an ID3v1 
tag and an ID3v2 tag, but foobar2000 will ignore the ID3v2 tag if it 
finds both.

6. ID3v1 tags always have certain fixed fields. foobar2000 is hiding the 
fields that it thinks are blank, which makes it hard to tell what it 
going on. Where is the comment? Where is the artist? Why does foobar2000 
feel they are blank, what are they filled with? They are a fixed number 
of bytes, so they are full of something. eyeD3 will show you what they 
are full of. foobar2000 will not, and if one of the fields starts with 
whitespace, foobar2000 may assume the whole field is empty, even though 
the value is " Irving Berlin" (that is a space character then Irving 
Berlin, a valid artist name).

Also, it is not clear what you want to achieve eventually. No matter 
what you want to achieve eventually, it seems to be related to the 
metadata inside the MP3 files. I do not recommend using foobar2000 to 
analyze the metadata inside the MP3 files.

If your goal is to get certain metadata to appear specifically inside 
foobar2000, that is okay. But you need to be able to analyze the 
metadata with a more predictable and robust tool, such as Mutagen or 
eyeD3, because otherwise it will be 100 times harder to figure out where 
foobar2000 is reading data from. Where did "Lavf" come from in the 
screenshot above? I gave at least four possibilities, and I can think of 
more. Using eyeD3, you can manually set each of them to a different 
thing and then see what foobar2000 says. Then, you will see where it is 
reading from. Beware: foobar2000 will probably read from different 
places based on whether there is an ID3v1 tag, an ID3v2 tag, a LAME Info 
Tag (or not), and whether it can find something "good looking" when it 
searches the header of the MP3 file for ASCII strings.

All that said, foobar2000 is an impressive and influential music player. 
It had the "up next" feature working, and working well, before any other 
music player that I am aware of, and foobar2000 had "up next" a full ten 
years before Apple iTunes added it. iTunes has an enormous budget, and 
people love this feature, so that is impressive. Although foobar2000 
itself is proprietary and closed-source, the SDK works well and it gave 
rise to a vibrant ecosystem of plugins, and this sparked innovation and 
allowed community-driven invention and refinement of new features in a 
way that was not possible for iTunes and simply was not happening on the 
media players that actually were Free Software. I think this tide has 
shifted in the past 5 or 10 years such that the innovation is now taking 
place in purely Free Software media players such as Quod Libet, which 
has a Python API and can also send and receive messages via text files 
on the hard drive, which is hilarious but also extremely portable and 
powerful. Nonetheless, there was a period of multiple years where the 
boom of music player innovation was happening around foobar2000.

You might really like Quod Libet, by the way. foobar2000 has not gotten 
significant new code in a long time. In that time, many of the Free 
Software media players have gotten a lot better.

Zak