Gmu 0.6.1 Released

[pder]

I looked around and could not find the source code for this. Is it available?

 

[sbock]

There is another little bug with Gmu I noticed even before 0.6.1. Sometimes the track number is shown falsely as "0". I'm not quite sure what the reason is. With Winamp and Tag&Rename the track is correctly shown. File type is ID3v2.3.0.

Regards,
Stephan

 

[wejp]

Thanks for the update !
I've got a dedicated SD card for Gmu and musics
I asking myself how much can I safely underclock my gp2x without trouble while reading flac or ogg vbr ? If anybody had already test that, please share your results !

Thanks again !

With FLAC it should be possible to go down to at least 80 MHz, maybe even less, with Ogg Vorbis 100 MHz should be possible. Btw, Musepack files can be played with 80 MHz as well.

I looked around and could not find the source code for this. Is it available?

No, currently not. As long as I am still developing Gmu I have decided not to release the source. It is rather likely that I will eventually release the source, but not as long as I still have (bigger) things in mind I want to implement.

There is another little bug with Gmu I noticed even before 0.6.1. Sometimes the track number is shown falsely as "0". I'm not quite sure what the reason is. With Winamp and Tag&Rename the track is correctly shown. File type is ID3v2.3.0.

Is there a way I can create such ID3 tags myself? Do you know which program has been used to create those tags that appear with 0 as the track number?

 

[sbock]

As I wrote in my previous post the programs I use are Winamp (5.34) and Tag&Rename. I put a file with a Track 0 display on my server. It's a file with shouldn't break any copyright law.

Testfile.

Regards,
Stephan

 

[IcantDeleteThisAccount]

Sometimes I noticed crashes at the start of Gmu in reduced power mode, too. I'm not quite sure if it's exactly the power option, but now I'm only reducing the speed with Gmenu2x without activating the option in Gmu and noticed no crashes so far. The device is a F-200.

Just one feature request, wejp. Gmu is near perfection for me. The only feature I'm really missing is any kind of lyrics support. Do you see any chance of adding this feature?

Regards,
Stephan

I have F-100, its usually does it when I start the program up. All the songs will play faster. Its sort of hit and miss. It did this occasionally in your earlier release but now it does it quite often. The crashing happens in low power mode, and rarely in normal powermode.

 

[wejp]

Thanks for the testfile sbock!

All the songs will play faster. Its sort of hit and miss. It did this occasionally in your earlier release but now it does it quite often.

So am I getting this right? All files play faster, no matter if it is Ogg Vorbis, MP3 or something else and no matter which sampling rate is being used? Does it happen in both normal and low-power mode?

Is there anybody else who is experiencing the same problem (files being played too fast)?

 

[doc5avage]

I've seen this before. I use madplay2x to launch some mp3 playback before launching an app. It seems to occur either when the screen goes black when launching the next app from gmenu2x, or when the cpu clock is adjusted by gmenu2x at the same time.

My work-around in this situation is to launch the app directly from the madplay2x script, rather than launching madplay2x, then from gmenu2x launching the other app.

Hope this helps, or is related.

 

[jjplano]

simply the best audio player for gp2x

cheers

 

[wejp]

There is another little bug with Gmu I noticed even before 0.6.1. Sometimes the track number is shown falsely as "0". I'm not quite sure what the reason is. With Winamp and Tag&Rename the track is correctly shown. File type is ID3v2.3.0.

Regards,
Stephan

The problem was caused by my assumption that only numbers could appear in the track number field of ID3 tags, which is not true. In case of the test file the value was "01/01". Converting that into a number resulted in 0 instead of 1. In the next Gmu version the track number will be treated as a string, so it will show up correctly as "01/01".

I've seen this before. I use madplay2x to launch some mp3 playback before launching an app. It seems to occur either when the screen goes black when launching the next app from gmenu2x, or when the cpu clock is adjusted by gmenu2x at the same time.

My work-around in this situation is to launch the app directly from the madplay2x script, rather than launching madplay2x, then from gmenu2x launching the other app.

Hope this helps, or is related.

Thanks for the hint. It might have something to do with the cpu clock change.

simply the best audio player for gp2x

cheers

Thank you.

 

[sbock]

There is another little bug with Gmu I noticed even before 0.6.1. Sometimes the track number is shown falsely as "0". I'm not quite sure what the reason is. With Winamp and Tag&Rename the track is correctly shown. File type is ID3v2.3.0.

Regards,
Stephan

The problem was caused by my assumption that only numbers could appear in the track number field of ID3 tags, which is not true. In case of the test file the value was "01/01". Converting that into a number resulted in 0 instead of 1. In the next Gmu version the track number will be treated as a string, so it will show up correctly as "01/01".


Interesting. I thought about this limits before and try to change the tag back to a pure number format but sometimes the track still shows "0". But perhaps Winamp don't rechange the tag correctly and the are still invisible strings left. But very good you found the problem and the change to string format is a nice feature...

Regards,
Stephan

 

[IcantDeleteThisAccount]

I've seen this before. I use madplay2x to launch some mp3 playback before launching an app. It seems to occur either when the screen goes black when launching the next app from gmenu2x, or when the cpu clock is adjusted by gmenu2x at the same time.

My work-around in this situation is to launch the app directly from the madplay2x script, rather than launching madplay2x, then from gmenu2x launching the other app.

Hope this helps, or is related.

That did help, putting the cpu clock speed back up was exactly what I needed to stop the crash. Alas the super speed stuff still happens..

 

[Micket]

I've seen this before. I use madplay2x to launch some mp3 playback before launching an app. It seems to occur either when the screen goes black when launching the next app from gmenu2x, or when the cpu clock is adjusted by gmenu2x at the same time.

My work-around in this situation is to launch the app directly from the madplay2x script, rather than launching madplay2x, then from gmenu2x launching the other app.

Hope this helps, or is related.

That did help, putting the cpu clock speed back up was exactly what I needed to stop the crash. Alas the super speed stuff still happens..


From my experience with oldplay, changing cpu clock speed (just changing it at all) along with opening and closing audio (which is needed when you start a program and when you need to change the samplerate) the GP2X may randomly:
1. Freeze, and i mean REALLY freeze. Just no the program but the entire gp2x will freeze.
2. Have no audio at all. Will freeze when you try to close audio.
3. Play to fast, that is, SDL_OpenAudio lies about the samplerate when you open audio.

I have not experienced this a single time if i leave the dont touch the clock speed at all within oldplay.
I suspect this bug is similiar? Perhaps faulty SDL or GP2X.

 

[wejp]

From my experience with oldplay, changing cpu clock speed (just changing it at all) along with opening and closing audio (which is needed when you start a program and when you need to change the samplerate) the GP2X may randomly:
1. Freeze, and i mean REALLY freeze. Just no the program but the entire gp2x will freeze.
2. Have no audio at all. Will freeze when you try to close audio.
3. Play to fast, that is, SDL_OpenAudio lies about the samplerate when you open audio.

I have not experienced this a single time if i leave the dont touch the clock speed at all within oldplay.
I suspect this bug is similiar? Perhaps faulty SDL or GP2X.

Yes, your experience is the same as mine. Changing the clock speed while the audio device is opened seems to be a very bad idea. But I don't really understand why it is a problem to change the clock rate _before_ doing anything with the audio device.
Currently I do change the cpu clock only right after Gmu starts - nothing has been done to the audio device until then. That still seems to crash the GP2X once in a while.

novaslogic: About the songs being played to fast. When does it happen? Does it seem to happen randomly or is there one file that triggers other files being played at the wrong speed. It would especially be interesting to know what sampling rates and file formats have been used.

 

[Micket]

Yes, your experience is the same as mine. Changing the clock speed while the audio device is opened seems to be a very bad idea. But I don't really understand why it is a problem to change the clock rate _before_ doing anything with the audio device.
Currently I do change the cpu clock only right after Gmu starts - nothing has been done to the audio device until then. That still seems to crash the GP2X once in a while.

novaslogic: About the songs being played to fast. When does it happen? Does it seem to happen randomly or is there one file that triggers other files being played at the wrong speed. It would especially be interesting to know what sampling rates and file formats have been used.

I always close and reopen audio whenever i change the clockfrequency, so from that point of view oldplay should also be safe, but alas, it is not.
The bug might be unrelated, but playing to fast can also be related to this one bug with clockfrequencies.
Even setting the clockfrequency back up to it's original value won't help in that case, as long as you still touch the register it will happen. At least thats what my experience tells me.