I was trying to use tinytag.TinyTag.get(filename), but it errored and said tinytag.tinytag.TinyTagException: mp3 parsing failed. Now I get that this means the mp3 is invalid, but the weird thing is: It works with ffplay, VLC and WMP (and probably all music playing software)

File was downloaded using youtube_dl, not sure if that matters.

Traceback (most recent call last):
  File "D:\Program_Files\Python\lib\site-packages\tinytag\tinytag.py", line 311, in _determine_duration
    frame_bitrate = ID3.bitrate_by_version_by_layer[mpeg_id][layer_id][br_id]
TypeError: 'NoneType' object is not subscriptable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\Program_Files\Python\lib\site-packages\tinytag\tinytag.py", line 94, in get
    tag.load(tags=tags, duration=duration, image=image)
  File "D:\Program_Files\Python\lib\site-packages\tinytag\tinytag.py", line 115, in load
    self._determine_duration(self._filehandler)
  File "D:\Program_Files\Python\lib\site-packages\tinytag\tinytag.py", line 313, in _determine_duration
    raise TinyTagException('mp3 parsing failed')
tinytag.tinytag.TinyTagException: mp3 parsing failed

This is my first time using tinytag I have a collection of 75000 mp3s Turns out that one of the files had 1/4/4/4/4/4 stored in the "disc" tag which made _set_field crash

If you change the lines from current, total = str(value).split('/') #which of course only works if the value is xx/xx

to this: splits = str(value).split('/') current, total = splits[0], splits[1]

it will work every time

Describe the bug When I trying to get file duration: TinyTag.get(filename).duration

and for some files I have exception:

    return TinyTag.get(filename).duration
  File "/opt/virtualenvs/lib/python3.6/site-packages/tinytag/tinytag.py", line 194, in get
    tag.load(tags=tags, duration=duration, image=image)
  File "/opt/virtualenvs/lib/python3.6/site-packages/tinytag/tinytag.py", line 212, in load
    self._determine_duration(self._filehandler)
  File "/opt/virtualenvs/lib/python3.6/site-packages/tinytag/tinytag.py", line 655, in _determine_duration
    xframes, byte_count, toc, vbr_scale = ID3._parse_xing_header(fh)
  File "/opt/virtualenvs/lib/python3.6/site-packages/tinytag/tinytag.py", line 604, in _parse_xing_header
    vbr_scale = struct.unpack('>i', fh.read(4))[0]
struct.error: unpack requires a buffer of 4 bytes

Expected behavior I think that the file is damaged but tinytag should return 0 for duration, not raising strange exception. Or raising own exception.

Sample File I can't upload it :(

I wanted to install this to check it out via pypi or pip but first it needs a setup.py, so here you go.

I also move the tests to the top level, and the code out of init and into tinytag.py

setup.py gets the version number from tinytag/init.py

note: You can run tests with ./runtests.py

I changed this line to return self._unpad(codecs.decode(x, 'gbk')) got the correct meta data. https://github.com/devsnd/tinytag/blob/e9b301d9a9bc2e7645c3b6364a593ce09c32736a/tinytag/tinytag.py#L607

Add an option of encoding? or other solution?

Hi,

Any VBR mp3 file I point tinytag at gives me a bitrate value which is about 1000x what audio software reports. I expect that this value is bps rather than kbps.

For example, for the file at (https antisol dot org slash brass dot mp3), tinytag gives me a bitrate value of 195206.785168, whereas various audio software reports the file as being 195kbps, including:

• audacious
• qmmp
• vlc ('input bitrate' on 'statistics' screen lists ~195kbps, but codec info tab shows 128kbps)

I've seen this with all other VBR mp3 files I've tried, they all give a value ~1000x the value reported by audacious.

As a workaround I was able to do something like:

if bitrate > 320: bitrate = bitrate / 1099

to get a pretty good bitrate value. But it would be nice to see a more accurate value come from TinyTag.

Thanks!

Thanks for the great library. I'm using it to build a script to automatically file audio files in a correct location and it's been really helpful.

However, I have several multiple-disc albums where track numbers are duplicated on each disc. The actual disc number is stored in the disc number part of the track. However, tinytag doesn't seem to read this information. Any chance for adding this in a future release?

I could give it a shot myself, but I have no idea about FLAC / OGG / MP3 ID3tag specifications and wouldn't know where to actually find this information. What sources did you use in order to implement tintytag?

Hi, not sure if this is an issue, or I am not using TinyTag properly!

I am using tinytag to get image data embedded in my audio files, and passing the image data into PIL/Pillow. i have noticed that some of the image data cannot be loaded. upon closer inspection of the data, it appears that I am getting a strange 10 B prefix for all of the ones that fail.

Here's a code fragment:

from tinytag import TinyTag
from PIL import Image
import io

filename = 'some/path/to/a/file.mp3
tags = TinyTag.get(filename, image=True)
image_data = tags.get_image()
img = Image.open(io.BytesIO(image_data))
# ^^^ this will fail for *some* of my audio files

I noticed that it is consistent which files fail and which pass, so it must be something with my audio files. when i print out the start of the data for one of these, and compare it to a file that is OK, i see a difference:

Good File: b'\xff\xd8\xff\xe0\x00\x10JFIF....' Bad File: b'o\x00v\x00e\x00r\x00\x00\x00\xff\xd8\xff\xe0\x00\x10JFIF......' so, it looks like the Bad File has a prefix of 10 bytes, followed by the same start as 'good file'. b'o\x00v\x00e\x00r\x00\x00\xoo' (does that say 'o v e r ' ?? weird...)

is this expected? i'm not sure why this is showing up, and only for some audio files. my script seems to work just fine if i do this:

if image_data[:10] == b'o\x00v\x00e\x00r\x00\x00\x00':
    image_data = image_data[10:]

but this feels a bit clumsy!

anyway, thanks in advance for taking a look! I can provide my audio files for you if needed.

Hello. I open this ticket which seems to correspond to #37. I have an album with tracks about twice as long as their true duration. I send a mp3 file by email.

Describe the bug tinytag currently returns an incorrect bitrate and duration for several VBR encoded MP3 files, as seen in this screenshot:

There seem to be two issues that are causing this:

The number of audio channels is included in this calculation, but it shouldn't be here: https://github.com/devsnd/tinytag/blob/2d6d51b2797565293d17b0029ad03107bceef6a0/tinytag/tinytag.py#L620

If we change the line to self.duration = xframes * ID3.samples_per_frame / float(self.samplerate), the situation improves somewhat:

There's still another issue that should be addressed in order to retrieve correct info for all files. samples_per_frame is always set to 1152. This is valid for MPEG-1 Audio Layer III, but the value should be 576 for MPEG-2 Audio Layer III and MPEG-2.5 Audio Layer III (lower sampling rates).

To Reproduce Let tinytag parse the sample files.

Expected behavior tinytag should return the same duration for all attached files, a bitrate of 32 kbps for files with a sampling rate of >=32 khz, and a bitrate of 8 kbps for files with a sampling rate of <32 khz.

Sample File vbr_samples.zip

I have a preliminary change in my fork of the library that supports extraction of the USLT lyrics tag if present in mp3 files, using for my own benefit. Should I submit a pull request for that if there's any interest in using it?

There are a number of utilities out there (e.g., Lyrics Finder, mp3tag, etc.) that find and add lyrics to mp3 files for you, which I used to enhance my own music library. I've been tinkering with tinytag for a python search project on my own and thought I would add this to it.

Is your feature request related to a problem? Please describe. I'm using watchdog to watch for music file changes in the file system. I am currently passing a list of file extensions that should trigger events like this:

...

PatternMatchingEventHandler.__init__(
    ...
    patterns=["*.flac", "*.mp3"],
    ...
)

...

I want to trigger events for all files that are supported by TinyTag. Can you expose a list or set of supported file extension that we can use for this purpose? I have checked #53 and the solution there does not work for this specific problem.

Describe the solution you'd like A simple list of supported formats. For example:

>>> TinyTag.SUPPORTED_EXTENSIONS
[".mp4", ".mp3", ".flac", ...]

Describe the bug I added a custom field (via mp3tag) to audio files of various types, but that custom field only appears in tinytag's extra collection for the mp3 files and not the m4a files.

To Reproduce

1. Unzip the Songs.zip attachment to find two files - both have a custom tag called KPL_DATE with the value TEST_DATE
2. Dump the tags for the two contained files using tinytag: python3 -m tinytag --format json Symphony1.m4a Symphony2.mp3
3. See that the custom tag is listed in extra for the mp3 file but not for the m4a file.

Expected behavior The custom tag is listed under extra for both files

Sample File Songs.zip

Audible's proprietary .aax format uses the adrm atom (under an aavd atom, which is just a renamed mp4a atom) to store data that external tools need to decrypt the encrypted AAC audio. Also, I was able to test one of the commented out data atoms, extra.description. Just had to add the extra. to the front of description. I can provide a sample audio file if you'd like to verify it further.

Describe the bug I have a program that captures album information from my collection to a spreadsheet. Files tagged with TDRC came up with an empty year cell.

This change to 1.8.1 caused tinytag to capture the tag to .year, instead of "extra.tdrc" 490c490 < 'TYER': 'year', 'TYE': 'year',

    'TYER': 'year', 'TYE': 'year', 'TDRC': 'year',

501a502

'TDRC': 'extra.tdrc',