Could you try ripping that album to Ogg Vorbis, and seeing if the truncation
still occurs?  This would help locate where the problem is occuring.

Good call; tagged correctly when ripping to Ogg Vorbis.

I should have mentioned my MP3 gstreamer pipeline is:
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc preset=standard

Looks like a very strange gstreamer bug then, re-assigning.

Perfectly normal since the id3 tagger uses the idv3 1.1 tagging format which has
a 30 characters limitation for the fields.
More info here : http://www.id3.org/history.html

"the first track lists the album name correctly in the mp3 files metadata, but
the second track onwards the long albumn name is truncated."

Why is the first file tagged differently, with the full title?

Evan, can you put some sample files online?

Thanks for re-opening.

Sample files are on http://www.alphalink.com.au/~pbclarke/
Track 01 lists full correct albumn name in nautilus properties, but track not
track 02.

To save space I have encoded this with the following gstreamer string:
audio/x-raw-int,rate=44100,channels=2 ! lame name=enc bitrate=8 mode=3

I noticed that they don't play properly at all, all stuttery in mplayer and
totem, but you can still see the metadata problem.

Copying Jan for comment

Here's an incomprehensible dump from 02\ -\ Dust_Me_Selecta.mp3. Keen readers will notice that at byte 0x88, there's a mysterious ID3 Version *1* tag, appended to the correct ID3v2 tag. 

Why is this? Well, I guess it ties in with bug #320767 and gstreamer's lame element inserting extra ID3v1 tags when encoding, coupled with the mad mp3 decoder interpreting the id3v1 tag it finds in the middle of the stream and sending a new TAG event that overrides the correct information in the ID3v2 tag.

Thie same playback part of this sequence doesn't seem to happen in 0.10, for reasons that the spirits have not yet revealed to me, but the end result is that (with the new non-libid3tag based id3demux) we end up only listing the correct tag information.

00000000  49 44 33 03 00 00 00 00  00 7d 54 53 53 45 00 00  |ID3......}TSSE..|
00000010  00 0d 00 00 00 4c 41 4d  45 20 76 33 2e 39 36 2e  |.....LAME v3.96.|
00000020  31 54 49 54 32 00 00 00  10 00 00 00 44 75 73 74  |1TIT2.......Dust|
00000030  20 4d 65 20 53 65 6c 65  63 74 61 54 50 45 31 00  | Me SelectaTPE1.|
00000040  00 00 08 00 00 00 47 65  72 6c 69 6e 67 54 41 4c  |......GerlingTAL|
00000050  42 00 00 00 24 00 00 00  57 68 65 6e 20 59 6f 75  |B...$...When You|
00000060  6e 67 20 54 65 72 72 6f  72 69 73 74 73 20 43 68  |ng Terrorists Ch|
00000070  61 73 65 20 74 68 65 20  53 75 6e 54 52 43 4b 00  |ase the SunTRCK.|
00000080  00 00 02 00 00 00 32 54  41 47 44 75 73 74 20 4d  |......2TAGDust M|
00000090  65 20 53 65 6c 65 63 74  61 00 00 00 00 00 00 00  |e Selecta.......|
000000a0  00 00 00 00 00 00 00 00  47 65 72 6c 69 6e 67 00  |........Gerling.|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 57 68  65 6e 20 59 6f 75 6e 67  |......When Young|
000000d0  20 54 65 72 72 6f 72 69  73 74 73 20 43 68 61 73  | Terrorists Chas|
000000e0  65 20 74 68 00 00 00 00  00 00 00 00 00 00 00 00  |e th............|

While I'm tuned into the psychic messages from the spirit world, I'm also going to go ahead and predict that the stutteriness exhibited on playback is due to these files being MPEG "2.5" audio files, with only an 8khz samplerate, and some element in 0.8 not doing timestamping correctly. Again, this is working properly here in 0.10.

audioscale in 0.8.11 didn't timestamp properly (fixed in CVS), that would explain the stuttering/choppy playback.

so, what's up with this?

The ID3 tag strangeness should be fixed in 0.10 with the recent work on the ID3 muxers, I believe. That's probably the best we can do - the tags are impossible to read and I think id3demux is already doing best-effort there.

Closing given that it works in 0.10 and I can't see anyone looking into this for 0.8...