New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show vendor-string in file properties #9

Closed
lazka opened this Issue Mar 14, 2015 · 7 comments

Comments

Projects
None yet
2 participants
@lazka
Member

lazka commented Mar 14, 2015

Original issue 9 created by bengunnink on 2008-09-10T15:44:19.000Z:

This is only a personal preference, but I'd like the see vendor strings
(and anything else useful) exposed in the file properties .

e.g. If I view the properties for a flac file, I want to know what version
of flac it was encoded with. The same goes for just about every codec.

As a disclaimer, this is blatant foobar2000 fanboyism: I've learned to
love this behavior about foobar2000, and I find it hard to use Linux audio
players because they don't expose enough data about my files.

The attached screenshot is an example with a Lame-encoded MP3 file (I don't
have any flac files here at work)

@lazka

This comment has been minimized.

Member

lazka commented Mar 14, 2015

Comment #1 originally posted by joe.wreschnig on 2008-09-14T00:23:42.000Z:

<empty>

@lazka

This comment has been minimized.

Member

lazka commented Mar 14, 2015

Comment #2 originally posted by mocaeruk@guerrillamail.org on 2008-12-02T06:24:05.000Z:

<empty>

@lazka

This comment has been minimized.

Member

lazka commented Mar 14, 2015

Comment #3 originally posted by simonharrison.uk on 2008-12-16T13:35:46.000Z:

This would be a very useful feature. It can be needed if bugs are found in encoder
and you have to re-encode. A second related feature is getting the full Lame version.
Here is a snippet from Hydrogen Audio:

phwip
Dec 10 2003, 05:11
Unfortunately this truncated value is all that is stored in the LAME Tag. So it is
not an issue with not retrieving all the information, simply that it is not there.

The same problem occurs with version strings such as "3.93.1" and "3.94a14" which are
all truncated: you will see the same effect if you view the version string from the
LAME tag in Encspot, Frontah or any other utility that reads it from there. The LAME
Tag spec only allows for 5 characters to be stored.

I think that some versions of LAME write a longer version string into other places in
the mp3 file. Frontah seems to read this, so there are cases where it shows the
truncated version string on the "Lame Tag" tab, but shows a full string on the "File
Info" tab.

LameTag.exe was only ever intended to read information from the LAME Tag. I don't
wish to get into reading information from other places within MP3 files. There are
other utilities such as Frontah and Encspot that do this much better and in greater
depth than I ever could.
getID3()
Dec 10 2003, 09:13
In versions prior to 3.90 LAME would store up to 20 bytes of version information, for
example: "LAME3.80 (alpha 1)". With the introduction of the LAME header tag in 3.90
the version information was trucated to 9 bytes ("LAME3.80 ") which is unfortunately
one or two bytes too short to store things like "LAME3.90.3" or "LAME3.94a14". So
that's why LameTag (and getID3()) only return the truncated versions of the version
string.

There is usually padding in the last frame in which LAME tries to write the longer
version string, but there may or may not be room for the full version string, and
it's not in any defined location. An aggressive program may scan for this version
string at the end to find out if it's 3.90.2 or 3.90.3[/b] but that's not part of the
specs.

Full thread:

http://www.hydrogenaudio.org/forums/index.php?showtopic=13695

Many thanks.

@lazka

This comment has been minimized.

Member

lazka commented Sep 27, 2015

mutagen can now partly read this.

Any suggestions for tag names and content?

We currently have "~format" which contains a mix of codec/container format.
Generally there are 5 types of information per file:

  • Container Format (MP4)
  • Audio Codec (AAC)
  • Encoder Product/Name (LAME)
  • Encoder Description/Version (LAME 3.98)
  • Encoding Details (VBR, lossless, 2-pass CBR, ...)
@declension

This comment has been minimized.

Member

declension commented Sep 28, 2015

For my 2c, I'd say format should be de-munged / stricter (thus shorter). Likewise for codec, and then there should be a single encoding (or similar) tag which has a free-text, best-efforts version of the rest, e.g. LAME 3.98: VBR q=3

This should make sure the data is searchable without bloating to too many new tags.

@lazka

This comment has been minimized.

Member

lazka commented Sep 28, 2015

Sounds good

lazka added a commit that referenced this issue Oct 1, 2015

Add a ~codec tag. See #9
~codec shows the audio codec and falls back to ~format
in case the distinction isn't clear.

~format shows the container/file format

@lazka lazka closed this in 91e1c32 Oct 1, 2015

@lazka

This comment has been minimized.

Member

lazka commented Oct 1, 2015

Needs a library reload to take effect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment