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
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
