Tweet
The track/album name might be longer so it uses another frame in the id tag.
-
-
Hi all,
I was intrigued by this problem when I saw it in the group, so I
decided to try it myself.
I use DMC 9a and Winamp 2.23. I couldn't find this problem with
any of the tracks (and in particular track 11).
It's a strange one, to say the least.
This won't help, but I wanted to share my experience....
Cheers,
Daren.Comment
-
Okay I will post the mp3s
The Length of the Track is not important because Track 5 is longer than Track 11 and is "normal"
And both Tracks have Id3v2 (ripped by dmc of course)
Track 5
Track 11
P.S. The Bug only appears when the Bitrate is set to 128kbit/s !!!!
Maybe this is why daren could'nt find the bug (I use newest Winamp Final 2.8)
P.S. Mp3Utility says about the 11. Track
Processing: C:\Dokumente und Einstellungen\Felix\Desktop\Temp\track11.mp3
Error: Sync error reading frame header 2 expected at byte 1,017. Approx. time: 0:00 (0% through audio).
Resync failed (no matching frame header found within 2,000 bytes).
Summary: 1 total frames processed (1 padded, 0 unpadded). Bitrate is constant.
And mp3gain 0.7.5 also says mpeg 1.0 layer 2
bye ShaolinComment
-
Winamp says:
Size: 3957210 bytes
Header found at: 520 bytes
Length: 282 seconds
MPEG 1.0 layer 2
112kbit, 10840 frames
44100Hz Stereo
CRCs: Yes
Copyrighted: No
Original: Yes
Emphasis: CITT j.17
But in the main Winamp screen, it still says 128Kbps. I'd say it was a bug in Winamp - I'm using 2.8 too.
EncSpot says 128Kbps MPEG 1 layer 3, though it says the encoder is Gogo 3.0 or higher. Hmmm...Last edited by totalXSive; July 13, 2002, 04:36 PM.Comment
-
Do you tested Track 5 or 11?Comment
-
This was track 11. I haven't had time to do track 5.Comment
-
I also think winamp is buggy (and mp3gain and mp3utility too)
But what is different on every 11. Track ripped by dmc.. because all other ripped Tracks are "normal" for Winamp usw..Comment
-
Where can i get EncSpot ?!
ThX ShaolinComment
-
EncSpot 1.0 says for both Tracks Lame 3.92 (guess) and mpeg 1 layer 3
cu ShaolinComment
-
I was using EncSpot 2.0, which is supposedly more accurate (though I'm surprised at the number of Gogo entries its been giving me that are more likely to be Lame).
I think you should report this on the Winamp forums.Comment
-
EncSpot 2.0 also says Lame 3.92..
Okay i will post it there but can somebody tell me what is the difference between the 11. and all other Tracks?
Because that's important for the bug..
ThX ShaolinComment
-
Hi all,
This is what Winamp 2.23 reports for track 11:
Size: 3995270 bytes
Length: 399 seconds
MPEG 2.5 layer 3
80kbit, 7652 frames
11025hz Stereo
Private: Yes
CRCs: Yes
Copyrighted: Yes
Original: Yes
Emphasis: None
Freaky, 'cos in the main display I see 128kbps and 44kHz!!
Just for the record, I did my own tests at 128kbps VBR (DMC tag
editor reports "134kbps"). I just tried again with 128kbps CBR
and this still works fine for me.
I'm beginning to think it has something to do with the MPEG
frame header....
I just compared your files with mine using a HEX editor and they
look completely different. Did you really make these using DMC 9a
+ the LAME 3.92 codec???
Daren.Comment
-
Heeey,
Track 13 from one of my CD's gives this info in Winamp 2.23:
Size: 5857317 bytes
Length: 243 seconds
MPEG 1.0 layer 1
192kbit, 9353 frames
44100hz Joint Stereo
Private: No
CRCs: No
Copyrighted: Yes
Original: Yes
Emphasis: invalid
For a 128-224kbps VBR.
The info starts to get weird after track 10, with slight variations
in MPEG version, bitrate, etc...
I'll dig into the files with a HEX editor and see if I can get any
closer to the reason for the mis-information...
Daren.Comment
-
First, yes I make it with dmc 9a and the lame Version that comes with it (I think Lame 3.92)
It is very Interesting that every 13. Track (and not 11.) and that it is for you Mpeg 1 Layer 1 and not Mpeg 1 Layer 2 (like for me)
I used every Time CBR 128kBit
ThanX to you
cu ShaolinComment
-
The new Version of mp3gain now also says mpeg 1 layer 3 and works for this file=)
Yuppi!
cu ShaolinComment
Comment