next »

[Ian @ un4seen]

Yep, an update is up on the XMPlay page. Basically just an accumulation of the little changes made since the initial 3.3 release, but also with the addition of uber-fast skin loading, even big skins like iXMPlay should load pretty much instantly.

I'm told it also sorts out the mysterious OGGENC problem

[Mr_Rabid_Teddybear]

I'm told it also sorts out the mysterious OGGENC problem

I'm very sorry to say my problem persists....

Warning: Hole in data found at approximate offset 4500 bytes. Corrupted ogg.
Warning: Invalid header page, no packet found
Warning: Invalid header page in stream 1, contains multiple packets
New logical stream (#1, serial: 0000050e): type invalid
Warning: stream start flag not set on stream 1
Warning: sequence number gap in stream 1. Got page 1 when expecting page 0. Indicates missing data.
Logical stream 1 ended

[Brian]

A good little update - many thanks.

[Dotpitch]

I'm told it also sorts out the mysterious OGGENC problem

I'm very sorry to say my problem persists....

I've got it working like this now:

oggenc2_aoTuV -q %q -t %1 -a %2 -l %3 -d %4 -N %5 -o %o -

oggenc2_aoTuV is OggEnc v2.8 (libvorbis aoTuVb4.51) from www.rarewares.org/ogg.html. With the Xiph-build (the non-optimized one), you've got more chance that it works. %q is the quality you want, works from -1 (-2 with aoTuV) to 10, I know it works up to 7. Also, I found out that adding "-G %6" or "-c %7" results in a broken file.

[5 minutes later]
Great! Now it doesn't give any working ogg anymore .

If I run OggInfo on the file while it is being created, it reports a working ogg, even if the resulting ogg in the end if broken.
I'd say the problem is still mysterious. Ian sent me some modified versions and the last one actually worked with all OggEncs I had, but now it feels more like there's an external factor messing things up...

[Roj]

I'm reading all this stuff and all I keep thinking is "how is this XMPlay's problem?".  From where I'm sitting it looks like the encoders are broken and thus producing files that XMPlay can't deal with because they're broken.  If that's indeed the case, then why is the onus on Ian to fix it?

Terrific update, Ian.

[Mr_Rabid_Teddybear]

I'm reading all this stuff and all I keep thinking is "how is this XMPlay's problem?".  From where I'm sitting it looks like the encoders are broken and thus producing files that XMPlay can't deal with because they're broken.  If that's indeed the case, then why is the onus on Ian to fix it?

Terrific update, Ian.

Because this happens with all different versions of oggenc? Because this doesn't happen with the same oggencs used with other frontends? Think that makes it a XMPlay problem....

[Vague Rant]

I think people would have heard about it if the Vorbis encoder was broken.

[Roj]

I'm reading all this stuff and all I keep thinking is "how is this XMPlay's problem?".  From where I'm sitting it looks like the encoders are broken and thus producing files that XMPlay can't deal with because they're broken.  If that's indeed the case, then why is the onus on Ian to fix it?

Terrific update, Ian.

Because this happens with all different versions of oggenc? Because this doesn't happen with the same oggencs used with other frontends? Think that makes it a XMPlay problem....

I C - I was under the impression that it only happened with the most recent versions.

[ckjnigel]

Re: optimized Japanese oggenc2
I'm pretty sure there are differences.  I was happily using Stanley Hwang's MediaCoder with the Lancer late November 2005 build until I discovered there were some FLACs that wouldn't be encoded -- not even a logged warning that files were skipped!  It seems there's a problem with how tags are handled.  I subsequently noticed that the genre field is missing even when encoding is successful.
Fortunately, somebody in iRiver forums posted instructions on using foobar2000 special, ver 8.3.  That works fine. I think there's something clever in how Peter translates one tag format to id3v1 that makes it succeed.
As to why use the Blacksword/Lancer build: how about 25x-29x encoding speeds from FLAC!

[Ian @ un4seen]

I'm very sorry to say my problem persists....

I tried to email you a couple of times regarding testing stuff, but got no reply. Nevermind, with Dotpitch's assistance, here's an update that should finally sort it...

   www.un4seen.com/stuff/xmplay.exe

[Roj]

I'm very sorry to say my problem persists....

I tried to email you a couple of times regarding testing stuff, but got no reply. Nevermind, with Dotpitch's assistance, here's an update that should finally sort it...

   www.un4seen.com/stuff/xmplay.exe

If this works, will you be updating the .1 release with it?

[Mr_Rabid_Teddybear]

I tried to email you a couple of times regarding testing stuff, but got no reply. Nevermind, with Dotpitch's assistance, here's an update that should finally sort it...

   www.un4seen.com/stuff/xmplay.exe

Very sorry. Seems the mailaccount I've registered with on this forum are one I don't check so frequently these days. However, I will check it more often from now on....

Yupp!  That takes care of it. Valid files with all my testversions of oggenc. Foobar2000 now also reports "VBR joint stereo" for lame -V 2 --vbr-new encoded file. So all's hunky dory!

[Ian @ un4seen]

If this works, will you be updating the .1 release with it?

Yep. But I'd like to test the file type association registry modifications a bit more first.

[Roj]

If this works, will you be updating the .1 release with it?

Yep. But I'd like to test the file type association registry modifications a bit more first.

Okee - do keep us posted.