# \[X\] One mp3 album is read unusually slowly by Mp3tag (~10 sec)
**URL:** https://community.mp3tag.de/t/x-one-mp3-album-is-read-unusually-slowly-by-mp3tag-10-sec/15682
**Category:** No Bugs
**Created:** [April 25, 2014, 4:49pm UTC](https://community.mp3tag.de/t/x-one-mp3-album-is-read-unusually-slowly-by-mp3tag-10-sec/15682 "2014-04-25T16:49:08Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@ricky](https://community.mp3tag.de/u/ricky)
#### Post date: [April 25, 2014, 4:49pm UTC](https://community.mp3tag.de/t/x-one-mp3-album-is-read-unusually-slowly-by-mp3tag-10-sec/15682/1 "2014-04-25T16:49:08Z")
I have encountered one specific mp3 album
that is read unusually slowly by Mp3tag
(~10 sec while all other mp3 albums I have, are read instantly, in less than 1 sec)
I haven't noticed any unusual with these files tags .
(they are 11 320-kbps mp3's, of duration ~3 mins and without any embedded mp3 art cover)
Please PM me to send you links to download a track or the whole album.
Thank you.
PS. Using latest Mp3Tag v2.59a in win8.1 x64.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [April 25, 2014, 6:56pm UTC](https://community.mp3tag.de/t/x-one-mp3-album-is-read-unusually-slowly-by-mp3tag-10-sec/15682/2 "2014-04-25T18:56:33Z")
> [@ricky](#):
>
> ... album
> that is read unusually slowly by Mp3tag
> ...
What happens if you create a copy of the folder of the album and then read the files?
If this is quicker then I would assume that the files are spread all over the disc.
PS: Where do you think the bug should be? (you posted in the bug section)
---
### Author:  [@ricky](https://community.mp3tag.de/u/ricky)
#### Post date: [April 25, 2014, 7:12pm UTC](https://community.mp3tag.de/t/x-one-mp3-album-is-read-unusually-slowly-by-mp3tag-10-sec/15682/3 "2014-04-25T19:12:25Z")
> [@ohrenkino](#):
>
> What happens if you create a copy of the folder of the album and then read the files?
> If this is quicker then I would assume that the files are spread all over the disc.
>
> PS: Where do you think the bug should be? (you posted in the bug section)
I've tried that before posting my OP
(copying it -several times- in an external hard disk or as duplicate in the laptop hd)
and it made no difference at all.
All other albums, that I have saved in recent time,
all are read quickly by Mp3tag.
I suppose that these files might have some characteristic
that causes Mp3tag to read them slowly.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [April 25, 2014, 7:29pm UTC](https://community.mp3tag.de/t/x-one-mp3-album-is-read-unusually-slowly-by-mp3tag-10-sec/15682/4 "2014-04-25T19:29:20Z")
> [@ricky](#):
>
> I've tried that before posting my OP
> (copying it -several times- in an external hard disk or as duplicate in the laptop hd)
> and it made no difference at all.
>
> All other albums, that I have saved in recent time,
> all are read quickly by Mp3tag.
>
> I suppose that these files might have some characteristic
> that causes Mp3tag to read them slowly.
You may now burn the whole firework of checking the files with mp3val and mp3diags, rewrite the headers with foobar2000.
---
### Author:  [@ricky](https://community.mp3tag.de/u/ricky)
#### Post date: [April 25, 2014, 7:39pm UTC](https://community.mp3tag.de/t/x-one-mp3-album-is-read-unusually-slowly-by-mp3tag-10-sec/15682/5 "2014-04-25T19:39:32Z")
 I did't quote understand what you mean by
> [@ohrenkino](#):
>
> You may now burn the whole firework of
Anyway, I pressed "Remove Tags" (to a copy of the album folder) in Mp3tag,
and imported the tags via eg Tag Sources\>discogs
and the files are read instantly now.
---
### Author:  [@ricky](https://community.mp3tag.de/u/ricky)
#### Post date: [April 25, 2014, 8:49pm UTC](https://community.mp3tag.de/t/x-one-mp3-album-is-read-unusually-slowly-by-mp3tag-10-sec/15682/6 "2014-04-25T20:49:27Z")
And, what I also noticed is this:
I copied just 1 of the initial mp3 (with no art cover, neither embedded nor separate)
to a separate -new- folder,
launched Mp3tag to read that folder,
and after I pressed "Remove tag"
THEN it showed that it had embedded art cover (image/png, 60 KB, with embed file as Other) !
I confirmed that the separate file was now containing an embedded cover art
by using Beyond Compare (MP3 compare) to compare it to the initial mp3
After "Remove tag"
the reading is quick again.
Mp3Diags showed:
(for the initial mp3)
> [@](#):
>
> - ID3V2 tag doesn't have an APIC frame (which is used to store images).
> - ID3V2 tag has at least one valid APIC frame (which is used to store images) but no frame has a type that is associated with an album cover.
and
(for the mp3 with the tag removed, revealing the hidden cover art file)
> [@](#):
>
> - ID3V2 tag has at least one valid APIC frame (which is used to store images) but no frame has a type that is associated with an album cover.
So, the initial mp3 had tag corruption,
and removing the tags now fixed this and revealed the cover art file.
Therefore, that was the cause of the slow reading, I believe.
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [April 26, 2014, 7:29am UTC](https://community.mp3tag.de/t/x-one-mp3-album-is-read-unusually-slowly-by-mp3tag-10-sec/15682/7 "2014-04-26T07:29:03Z")
> [@ricky](#):
>
> ... I suppose that these files might have some characteristic that causes Mp3tag to read them slowly.
A few days ago I observed a similar behaviour using Mp3tag v2.59a.
The procedure was to store a cover picture, for completion an already textually tagged media file.
1. Original picture is a PNG file with properties ...
1300 x 1300, 300 dpi, 725 kB.
2. Using Irfanview I copied the PNG image to the clipboard.
3. Using Mp3tag Dialog "Extended Tags..." I inserted the clipboard content into the media file, and saved the media file.
It seems so that Mp3tag has converted the image from PNG to JPG with properties ...
JPEG, quality: 100, subsampling ON (2x2), 100 dpi, 698 kB.
4. I added one text data tag-field, and Mp3tag worked rather slow, about 20..30 percent as fast as before without the embedded cover image; the entire duration was about 8 minutes for 200 files.
After removing the image from the media file, the Mp3tag usual performance was restored, so that adding one text data tag-field was done in short time.
Then I tried the embedding process again.
1. Now the picture is a JPG file with properties ...
JPEG, quality: 80, subsampling ON (2x2), 159 kB.
2. Using Irfanview I copied the JPG image to the clipboard.
3. Using Mp3tag Dialog "Extended Tags..." I inserted the clipboard content into the media file, and saved the media file.
4. I added one text data tag-field, and Mp3tag worked as it behaved in the usual performance; the entire duration was about 1,5 minutes for 200 files.
I suspect that the slowdown occurs while Mp3tag creates and saves the "undo data."
I do not remember having seen this behaviour of slowing down, even when tagging media files having more than one embedded image.
DD.20140426.1128.CEST
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [April 27, 2014, 11:54am UTC](https://community.mp3tag.de/t/x-one-mp3-album-is-read-unusually-slowly-by-mp3tag-10-sec/15682/8 "2014-04-27T11:54:37Z")
> [@ricky](#):
>
>  I did't quote understand what you mean by
>
> Anyway, I pressed "Remove Tags" (to a copy of the album folder) in Mp3tag,
> and imported the tags via eg Tag Sources\>discogs
> and the files are read instantly now.
Sorry, that I did not express myself clearly.
I tried to point into the direction of trouble with the tags.
The tags could be checked with tools I mentioned.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [December 28, 2018, 2:34pm UTC](https://community.mp3tag.de/t/x-one-mp3-album-is-read-unusually-slowly-by-mp3tag-10-sec/15682/9 "2018-12-28T14:34:03Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.