PDA

View Full Version : One album showing up with no ID3 info in slimserver



Dan Goodinson
2005-01-13, 09:18
I had the same. In my case, it was only a couple of tracks that were
affected. Pretty much any application I used (other than SS) could read
the tags - I edited the tags over and over, but still couldn't get SS to
read them. It was only when I re-ripped the tracks that SS could see
them. The data in the tags was exactly the same each time, even after
re-ripping.

I just assumed it was a quirk in the original encoding that SS didn't
agree with.

-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of Marc Sherman
Sent: 13 January 2005 15:54
To: Slim Devices Discussion
Subject: [slim] One album showing up with no ID3 info in slimserver


Dan Goodinson wrote:
>
> If you re-ripped the tracks (with all the same tags) and the new files

> work fine, then the problem is not with the tag content (since the
> tags are the same). I don't believe it is a bug in SS, but more
> related to a problem with the original ripping process. (This is
> based on my own experience, too).

With the original files, I updated the tags a few times using id3v2
(which is a thin wrapper app for linux around id3lib,
http://id3lib.sf.net ). With those files, every tool I've tried*
_except_ for slimserver can read the tags. The second set of files I
got the tags right the first time, so I didn't have to update them.

* I tried a bunch of tools: id3v2 itself, windows media player (over a
samba share), id3ren (another linux tool, which doesn't use id3lib), QCD

(also on windows over the samba share).

- Marc

Marc Sherman
2005-01-13, 09:32
Dan Goodinson wrote:
>
> I just assumed it was a quirk in the original encoding that SS didn't
> agree with.

I think we're arguing semantics here. That's exactly what I think it
is, too. The only difference is that I consider that a slimserver bug
(and I think the devs would agree with me), while you don't.

It's quite possibly _also_ a bug in the tools I used to rip/tag, but
according to Postel's Law[0], it's not incorrect to consider this a bug
in both systems.
[0] http://www.catb.org/~esr/jargon/html/P/Postels-Prescription.html

- Marc

Geoff Bonallack
2005-01-13, 10:15
On Thu, 13 Jan 2005 16:18:42 -0000, Dan Goodinson
<Dan.Goodinson (AT) businessobjects (DOT) com> wrote:
> I had the same. In my case, it was only a couple of tracks that were
> affected. Pretty much any application I used (other than SS) could read
> the tags - I edited the tags over and over, but still couldn't get SS to
> read them. It was only when I re-ripped the tracks that SS could see
> them. The data in the tags was exactly the same each time, even after
> re-ripping.
>
> I just assumed it was a quirk in the original encoding that SS didn't
> agree with.

I had a lot of similar problems in my earlier days of ripping, and it
turned out to be reasonably simple: the files that were 'bad' had more
than one tag format included in the file, and the files that were
'good' had only one.

When I look at the two files you posted, the difference is in the
number of tag formats included:
bad-id3: ID3v2, APEv2
good-i3: ID3v1, ID3v2, APEv2

You might want to try removing all tags except ID3v2, and seeing
whether you still get the same result. I use MP3Tag for this (sorry,
I'm on Windows), but I'm sure there's plenty of tools out there to do
the same thing for Linux. If you like, I can do it and upload the
modified bad-id3.mp3 for you, if you tell me where to put it.

Cheers
Geoff

Marc Sherman
2005-01-13, 10:37
Geoff Bonallack wrote:
>
> When I look at the two files you posted, the difference is in the
> number of tag formats included:
> bad-id3: ID3v2, APEv2
> good-i3: ID3v1, ID3v2, APEv2

Really! That's interesting. Was it MP3Tag that told you what tags were
in the file? I have a windows box as well, so I'll give that a try.

Thanks for the info,
- Marc

Jason Holtzapple
2005-01-13, 10:42
Geoff Bonallack wrote:
> When I look at the two files you posted, the difference is in the
> number of tag formats included:
> bad-id3: ID3v2, APEv2
> good-i3: ID3v1, ID3v2, APEv2
>
> You might want to try removing all tags except ID3v2, and seeing
> whether you still get the same result. I use MP3Tag for this (sorry,
> I'm on Windows), but I'm sure there's plenty of tools out there to do
> the same thing for Linux. If you like, I can do it and upload the
> modified bad-id3.mp3 for you, if you tell me where to put it.

Are those APEv2 tags from mp3gain? If so try running mp3gain at the
very end of your ripping/encoding/tagging setup. I've had some recent
issues where id3v2 is clobbering APEv2 tags when you try to write
id3v1 tags as well.

kdf
2005-01-13, 10:50
Quoting Jason Holtzapple <jasonholtzapple (AT) yahoo (DOT) com>:

> Geoff Bonallack wrote:
> > When I look at the two files you posted, the difference is in the
> > number of tag formats included:
> > bad-id3: ID3v2, APEv2
> > good-i3: ID3v1, ID3v2, APEv2
> >
This may already be fixed in teh nightly builds. I don't see any 'no album' etc
links.

downloaded the linked file, cleared the cache. this is with 5.4.1 from cvs,
updated last week sometime:

2005-01-13 09:46:28.2031 updating genre cache with: LPD - Legendary Pink Dots -
The Maria Dimension - 11
--- for:file:///D:/mp3/test/bad-id3.mp3
2005-01-13 09:46:28.2031 Inc SongCount file:///D:/mp3/test/bad-id3.mp3
2005-01-13 09:46:28.2031 merging file:///D:/mp3/test/bad-id3.mp3
2005-01-13 09:46:28.2031 updating file:///D:/mp3/test/bad-id3.mp3 with mp3 for
CT
2005-01-13 09:46:28.2031 updating file:///D:/mp3/test/bad-id3.mp3 with Fourth
Secret for TITLE
2005-01-13 09:46:28.2031 updating file:///D:/mp3/test/bad-id3.mp3 with
1105637286 for AGE
2005-01-13 09:46:28.2031 updating file:///D:/mp3/test/bad-id3.mp3 with LPD for
GENRE
2005-01-13 09:46:28.2031 updating file:///D:/mp3/test/bad-id3.mp3 with 11 for
TRACKNUM
2005-01-13 09:46:28.2031 updating file:///D:/mp3/test/bad-id3.mp3 with 4796288
for FS
2005-01-13 09:46:28.2031 updating file:///D:/mp3/test/bad-id3.mp3 with 4794426
for SIZE
2005-01-13 09:46:28.2031 updating file:///D:/mp3/test/bad-id3.mp3 with 1572 for
OFFSET
2005-01-13 09:46:28.2031 updating file:///D:/mp3/test/bad-id3.mp3 with Legendary
Pink Dots for ARTIST
2005-01-13 09:46:28.2031 updating file:///D:/mp3/test/bad-id3.mp3 with The Maria
Dimension for ALBUM
2005-01-13 09:46:28.2031 updating file:///D:/mp3/test/bad-id3.mp3 with 1991 for
YEAR
2005-01-13 09:46:28.2031 updating file:///D:/mp3/test/bad-id3.mp3 with
180.636734693878 for SECS
2005-01-13 09:46:28.2031 updating file:///D:/mp3/test/bad-id3.mp3 with 77 for
VBR_SCALE
2005-01-13 09:46:28.2187 updating file:///D:/mp3/test/bad-id3.mp3 with 212000
for BITRATE
2005-01-13 09:46:28.2187 updating file:///D:/mp3/test/bad-id3.mp3 with ID3v2.3.0
for TAGVERSION
2005-01-13 09:46:28.2187 updating file:///D:/mp3/test/bad-id3.mp3 with 1 for TAG
2005-01-13 09:46:28.2187 updating file:///D:/mp3/test/bad-id3.mp3 with 1 for
BLOCKALIGN
2005-01-13 09:46:28.2187 updating file:///D:/mp3/test/bad-id3.mp3 with 1 for
VALID
2005-01-13 09:46:28.2187 updating file:///D:/mp3/test/bad-id3.mp3 with
1105638918 for TTL
2005-01-13 09:46:28.2187 Request for CT on file file:///D:/mp3/test/bad-id3.mp3
2005-01-13 09:46:28.2187 Request for TITLE on file
file:///D:/mp3/test/bad-id3.mp3
2005-01-13 09:46:28.2187 merging file:///D:/mp3/test/bad-id3.mp3
2005-01-13 09:46:28.2187 updating file:///D:/mp3/test/bad-id3.mp3 with 1 for
VALID

-kdf

Marc Sherman
2005-01-13, 11:05
Geoff Bonallack wrote:
>
> When I look at the two files you posted, the difference is in the
> number of tag formats included:
> bad-id3: ID3v2, APEv2
> good-i3: ID3v1, ID3v2, APEv2

This is really very strange. id3v2 doesn't see any difference in the
tags between the two files -- normally, if an id3v1 tag exists, it
reports that:

msherman@pyloric:/var/www/public$ id3v2 -l bad-id3.mp3
id3v2 tag info for bad-id3.mp3:
TIT2 (Title/songname/content description): Fourth Secret
TALB (Album/Movie/Show title): The Maria Dimension
TYER (Year): 1991
TRCK (Track number/Position in set): 11
TPE1 (Lead performer(s)/Soloist(s)): Legendary Pink Dots
TCON (Content type): LPD (255)
msherman@pyloric:/var/www/public$ id3v2 -l good-id3.mp3
id3v2 tag info for good-id3.mp3:
TIT2 (Title/songname/content description): Fourth Secret
TPE1 (Lead performer(s)/Soloist(s)): Legendary Pink Dots
TALB (Album/Movie/Show title): The Maria Dimension
TYER (Year): 1991
TRCK (Track number/Position in set): 11
TCON (Content type): LPD (255)

Jason Holtzapple wrote:
>
> Are those APEv2 tags from mp3gain? If so try running mp3gain at the
> very end of your ripping/encoding/tagging setup. I've had some recent
> issues where id3v2 is clobbering APEv2 tags when you try to write
> id3v1 tags as well.

Yes, quite possibly. Here's the script-fragment used to rip the file
with the good tags:

nice -n 5 lame -S --preset standard --noreplaygain \
"$WAV" "$TEMPDIR"/"$SONGFILE".mp3

id3v2 -2 -t "$SONGNAME" -a "$ARTISTNAME" -A "$ALBUMNAME" \
-y "$YEAR" -T "$TRACK" -g "$GENRE" \
"$TEMPDIR"/"$SONGFILE".mp3

nice -n 5 mp3gain -q -a -k -s r "$TEMPDIR"/*.mp3

The file with the bad tags went through a bunch of permutations. It
started with tags (id3v1) being added with Lame's -tX flags when the wav
was first encoded. Then mp3gain was run. After that, the id3v1 tags
were converted to id3v2 and stripped with "id3v2 -C; id3v2 -s". At some
point, I think I changed the artist tag to remove a leading "The" -- I
can't remember if I did that before or after converting the tags to
id3v2, though. That last part could well be why this issue only applies
to this album -- IIRC, this was the only album I did that to. Given all
that, I'm hardly surprised I messed up the tags somehow.

kdf wrote:
> This may already be fixed in teh nightly builds. I don't see any 'no
> album' etc links.
>
> downloaded the linked file, cleared the cache. this is with 5.4.1
> from cvs, updated last week sometime: [snip]

Ah, thanks. In that case, I won't bother filing a bug. What debug flag
did you use to get that output? I'd like to see what it says about
those files in my current version.

- Marc

kdf
2005-01-13, 11:16
Quoting Marc Sherman <msherman (AT) projectile (DOT) ca>:


> kdf wrote:
> > This may already be fixed in teh nightly builds. I don't see any 'no
> > album' etc links.
> >
> > downloaded the linked file, cleared the cache. this is with 5.4.1
> > from cvs, updated last week sometime: [snip]
>
> Ah, thanks. In that case, I won't bother filing a bug. What debug flag
> did you use to get that output? I'd like to see what it says about
> those files in my current version.

I ran from the command line with --d_info. turning on d_info from the web would
work too. To make it easier, place that file in a folder on its own, then set
that folder as the music folder and wipe the cache. If you don't you'll have
to find that song in the midst of all the rest.

What my test doesn't cover is the case where you might have an old reference to
that same song. The current server structure (5.4.x) doesn't handle multiple
references all that ideally. Something like an old playlist that already had
the file loaded when it had different tags might confuse things. However, all
that should have disappeared when you wiped the cache anyway.

-kdf

Geoff Bonallack
2005-01-13, 12:20
On Thu, 13 Jan 2005 12:37:42 -0500, Marc Sherman <msherman (AT) projectile (DOT) ca> wrote:
> Really! That's interesting. Was it MP3Tag that told you what tags were
> in the file? I have a windows box as well, so I'll give that a try.

Yes, if you are using the latest from:
http://www.mp3tag.de/en/

You need to add two columns, one to show the currently displayed tag
type and one to show all the tags included in the file. Right-click
the column headers, select "Customize columns", and click on add.
The field values are:

Name: Current Tag
Value: %_tag_read%

Name: Tags In File
Value: %_tag%

You can change which tag is loaded and displayed under:
Tools | Options | Tags | Mpeg | Read

To remove other tag types from the mp3, first go to:
Tools | Options | Tags | Mpeg | Remove
and check the ones you want to REMOVE from the file.
Then select the file, and use File | Remove Tag.
I do this last step as the last thing before adding the file to my
library, and end up with JUST ID3v2 tags in the file. For APE files,
I end up with just APEv2 tags.

Cheers
Geoff