Is anybody using alpha 5?

I've had alpha 5 on my main player for a couple of weeks now and I have to say I'm very impressed. Track changes seem to be instantanious now. The cross fading is cool. It also seems to no-gap all my gapped rips (which is very cool). Other than the rebuilding database problem, there only seems to be two things keeping it from being perfect.

1, The sound quality.... Does anyone else who's tried alpha 5 and suffered from stuck stereo separation other than myself and taym?

2, my nogapped rips seem to be truncated now. Which is a shame as I seem to have lost one of the albums in question. So it'll cost me a tenner to fix it.

Other than that, for an alpha i'd say it's bloody good....

suffered from stuck stereo separation

That's the only reason which is actually preventing me from using it. With upgrader.exe is not that bad to downgrade and upgrade to/from alpha3, so I would not even mind the dbase bug too much...

I'd use alpha 5 if I could.

wondering out loud... I wonder if a Beta is too far away...

I have to agree with you. I never tried alpha 3, but alpha 5 is cool. So far it has been stable for me. The only problems I have experienced are the database rebuilds, and stereo separation not being changeable. I haven't been looking for bugs, but in my day to day life its been good. I loaded my first OGG's today so now I get to play with that! Yay!

I have now noticed the odd impromptu reboot now and then. But since I've been loading new tracks, all of my players are now back at v2final.

Cheers

Well, my deck is full, and I don't really switch out music that often, so the database issue doesn't bug me. And maybe my ears don't work right, but I don't really hear anything wrong with the stereo seperation either. As Mark said, I get the (rare) hang-up, but I think that's been maybe 4 total since I loaded it on Christmas Eve...

Love it. Can't wait for the beta...

my nogapped rips seem to be truncated now.

If you did this by slicing up the MP3s themselves (either with MP3 trim or gapkiller or whatever), please have a look at the files and if they're VBR, make sure to use a tool to fix up the VBR headers. See if that fixes it.

No, i used --nogap in lame.

I have had one reboot with Alpha 5 since Christmas, which is a LOT better than alpha3 was. I have seen some minor bugs (very minor, like the crossfade sometimes messes up when hitting next track), but nothing to make me even come close to considering switching back to Alpha3...well except the DB rebuild bug. I was really hoping the Empeg guys would fix that and release a revised Alpha 5 real quick, but I understand how these things go and how busy they are.

No, i used --nogap in lame.

Which, if I recall correctly, also has VBR header problems. Definitely feed some test copies of those files to MP3 Tag Studio's VBR repair tool and see if it solves the problem.

please have a look at the files and if they're VBR, make sure to use a tool to fix up the VBR headers

Isn't --nogap CBR only ?

No. Actually, for a few iterations, I think it was, but it was because they thought it didn't work because of their VBR bug that actually affected all VBR files it made.

No. Actually, for a few iterations, I think it was, but it was because they thought it didn't work because of their VBR bug that actually affected all VBR files it made.

Ah, cool. I figured the problem must be with Lame's VBR header writer, not with the basic concept of VBR headers on --nogap files, but I didn't realise it affected other VBR files too.

Peter

I think it was you who did some research into what was causing the problem and resolved it by hacking lame to produce VBR nogap files, then running them through a VBR header fixer. Then I looked into the lame source and found that the problem was that it was always writing the VBR header to show one fewer frame than there actually was. The reason it did that was because it failed to count the VBR header itself, which is a valid mp3 frame. It turns out that that bug existed in all VBR files, but it was only really noticeable on nogapped files, as chopping the last frame off a track that has basically already faded out was unnoticeable.

It's been fixed in CVS for a while, but I don't think that there's been a release since then. Actually, it looks like there's just been a new release. Checking to see if the fix is in there and if VBR nogaps are reenabled...

It looks like it, but I'm too lazy to compile it and make sure.

Today I did see something with alpha 5. As I pulled up to work, the current song was close to ending (about 30 seconds). When I got off and put my empeg in, the same track started from the beginning. First time noticing it... maybe a fluke... I'll try to notice if it happens again.

I had that bug in Alpha 3 all the time. I have seen it once or twice in Alpha 5, but much rarer.

Yeah, now that I was aware of it, I saw it three more times today.

Before I posted last I was driving home listening to Josie and the Pussycats. Before pulling up in my driveway I switched playlists to listen to Linkin Park's Meteora. When I left for school it was back on the last Josie song I was listening to. I switched back to Linkin Park for my drive to school (listened to about 6 tracks).

Next I leave school to come back home, my empeg is playing a random song from the Josie soundtrack, not the one before!.

Right before shutting off my car and pull out my empeg, I'm into Rush 30 seconds, pull and re-insert my empeg, and it restarts with the same Rush song, but at 15 seconds.

I also noticed when selecting a new playlist, while another song is playing, it doesn’t stop playback to switch immediately like it did in 2.0

So I'm convinced it is a bug, although not a show stopper I will continue to use alpha 5. At first I was afraid of the crossfade, because I hated how winamp did it, but am pleased with the time being adjustable. 1/2 second suits me perfectly! Since I haven't no-gaped my MP3's, that addition is really cool too!

the problem of a track restarting to the beginning after pulling the power, or even going to a few tracks before, has always been a problem, because the dynamic partition, where the placeholder is stored, isn't written to all the time.

but speaking of which, will it really that much of a burden to program dynamic partition writes as the last action before the hdd spins down? or, if thats already the case, anyway to force a dynamic partition write?

Yes Andy

My stereo separation is terrible if not non-existant. I almost think it's playing in mono. Sounds quite muddy to me too.

I have a test track with a sequence of a guy saying "left channel, left centre, centre, right centre, right channel" with appropriate panning. This does not work at all with 3.0a5. In fact with balance hard left (I know right doesn't go to zero volume) when the guy says right channel, it's just as loud as when he says left channel.

Unfortunate really because apart from this and the odd crash 3.0a5 also seems pretty good to me.

I just can't explain why everyone was initially saying the sound quality had got better. Didn't make sense when I tried it and thought it was noticeably worse.

I have a test track with a sequence of a guy saying "left channel, left centre, centre, right centre, right channel" with appropriate panning. This does not work at all with 3.0a5. In fact with balance hard left (I know right doesn't go to zero volume) when the guy says right channel, it's just as loud as when he says left channel.

Is that something you wish to share ?

\\Kaare

Technically it's a copyrighted track on a car audio test disc (albeit with very little artistic content ), so I shouldn't really share it

It would take very little effort to do something similar in CoolEdit.

CH

I'm stuck in "No Stereo" land as well. It's really driving me nuts, to the point where I'm going to go back to A3 unless somebody has a fix for it.

Has anyone figured out exactly why it gets stuck...? Is it possible we could fix it with the config file, or through hijack, or...?

What sucks, is that I really love the stability of A5. It works much better for me. =/

If it was done by the DSP then there is a possibility you could disable it with Hijack. Unfortunately, I would say it's done in software - I don't remember reading anything about a stereo bleed function in the DSP manual

I'm back at 3.00a3 for exactly this reason. Started to find a few 3.00a5 issues though it is much more stable than 3.00a3

CH

I don't remember reading anything about a stereo bleed function in the DSP manual

Stereo bleed is implemented in software.

Any chance of switching this off? a5 is brilliant but the stereo bleed is doing my head in...