HippoPlayer v2.48

[yelworC]

As I said timidity and vgm2wav are both installed and work from shell.

MP3 with mhi driver works but without this setting hip reboot-crashes the whole Amiga.

Edit: I reverted back to hip 2.58 and mp3 works again with software decoding. There must be a bug in this pipe streaming thing in 2.59

[samo79]

Originally Posted by koobo

Have you checked if the HiP binary has the E flag set?
When unarchiving with "LhA 2.15" on Amiga the HiP binary will have the E flag and is executable as expected.

Yeah checked, works now :-)

[DisasterIncarna]

Originally Posted by yelworC

As I said timidity and vgm2wav are both installed and work from shell.

MP3 with mhi driver works but without this setting hip reboot-crashes the whole Amiga.

Edit: I reverted back to hip 2.58 and mp3 works again with software decoding. There must be a bug in this pipe streaming thing in 2.59

all working for me, im using OS3.2 in FS-UAE, midi files play, the new VGM/AY stuff plays as well, maybe there is some other "thing" causing an issue outside of HIP ?

as for the executable thing, worked out of the box for me, i used Filemaster3 to unlha it and it just worked, so not sure why we are getting mixed results here, it is interesting however.

[yelworC]

I dont think you are using a mhi driver in your uae setup. We figured out that enabling MHI in Hippo is causing trouble with the new pipe streaming formats.

[DisasterIncarna]

Originally Posted by yelworC

I dont think you are using a mhi driver in your uae setup. We figured out that enabling MHI in Hippo is causing trouble with the new pipe streaming formats.

you would be correct sir. back to figuring out why some ay tunes arent liked .

[EctoOne]

Originally Posted by DisasterIncarna

as for the executable thing, worked out of the box for me, i used Filemaster3 to unlha it and it just worked, so not sure why we are getting mixed results here, it is interesting however.

It is interesting. I would like to know how koobo creates the archive. Is it done on an (emulated) Amiga or a different system?

It is weird that LhA in this case does not seem to care about the file attributes. The output is the same for either LhA x hippoplayerupdate.lha and LhA x -a hippoplayerupdate.lha.

For something like SysPic400free.lha it makes a difference. Without the -a option to keep the attributes, everything will be set to RWED. While with that option you'll get some files missing the E flag.

While I was creating my custom install scripts I used xad to inspect the archives and had to add a few PROTECT lines to several packages.
This is the first time I've seen this behavior.

[koobo]

Originally Posted by yelworC

I dont think you are using a mhi driver in your uae setup. We figured out that enabling MHI in Hippo is causing trouble with the new pipe streaming formats.

To elaborate, playing MIDI/VGM/MDX revealed an issue which has been there from earlier when MHI support was added. If MHI is enabled it will attempt to play MIDI/VGM/MDX and also all sample formats (WAV, AIFF, IFF) using MHI but that will just lead to a crash, basically.

[koobo]

Originally Posted by EctoOne

It is interesting. I would like to know how koobo creates the archive. Is it done on an (emulated) Amiga or a different system?

I'm using "LHa for UNIX V1.14i" on a Mac to create the lha.

I switched to that at some point as an aminet moderator pointed out to me that the dates were buggy in the lha files I had uploaded, this was due to using some buggy Amiga LHa version apparently.

[daxb]

The old LHA version(s) hat that dates problem. LHA 2.15 should work: http://aminet.net/package/util/arc/lha_68k You may try it.

[EctoOne]

Since it is just the executable flag it would probably work if it just gets set for the next update. Assuming that it will keep it when archived on a Mac.
Might not work for any of the Amiga specific flags, like S for script for example. But again, it shouldn't matter in this case.

Another thing I've noticed is that LZX can't extract the archive at all. It returns the error: LZX does not support level 2 headers

[koobo]

The next aminet lha will be created in a more compatible manner so all unarchivers should produce an exe with the E-flag set (thanks @Patrik).

Both issues found by yelworC also resolved. These were:
- Enabling "MHI output" in Prefs and trying to play WAV/AIFF/MIDI/MDX2WAV/VGM2WAV will lead to crash.
- Setting "MPEGA freq div" to something else than 1 and playing mp3 will also lead to a crash. This will engage the relatively new and improved mp3 downsampling code which can't handle non-44.1kHz input data.

Thanks for the findings!

[DisasterIncarna]

A long standing issue i have had with MP3 playback btw is that seemingly quite randomly an MP3 will sound glitched/crackly on occasion, never happens on a "First" played MP3, but typically on a new MP3 or one i have had on repeat/loop for a while. As it is random and i cant make it happen i have always just quit hippo and relaunched as it is that infrequent but it does happen, much more noticable when i am wearing my headset rather than using monitor output.

[tygre]

Hey Koobo!

Thanks for this new version!

I used my usual set of modules to test v2.59 and here is some feedback:

• Text files, at least ones with the .url extension, cause HiP to make "hits", see Hits 1 in the attachment.
• Some Impulse Tracker files are not recognised, like the one in the attachment.
• MED files are now correctly excluded from the playlist.
• MMD3 files now play correctly.
• MIDI files cause a requester to open for "timidity".
• ML files (Music Line Editor) cause my screen to jump. (Probably due to my particular config.)
• MP2 and MP3 files cause HiP to make "hits", see Hits 2 in the attachment. Although the CPU is not 100%, any action causes the music to "stutter".
• RSID files sometimes cause HiP to make "hits", and sometimes are excluded from the playlist... hard to reproduce.

Cheers!

[koobo]

Thanks tygre for testing! Some comments below, unfortunately I cannot reproduce the issues you have

Originally Posted by tygre

Text files, at least ones with the .url extension, cause HiP to make "hits", see Hits 1 in the attachment.

I get "Unknown file format" when trying to load the test file.

Some Impulse Tracker files are not recognised, like the one in the attachment.

"it.siatek 2 - happy bee" works here correctly.

MIDI files cause a requester to open for "timidity".

This happens if Hippo does not find the assign "timidity:", do you maybe have this?

RSID files sometimes cause HiP to make "hits", and sometimes are excluded from the playlist... hard to reproduce.

Trying to open an RSID file should display a requester with "RSID format not supported!" text.

The hits reported all seem to be in the kickstart code, so it's very difficult to see where the possible problem lies. If you want to examine further you could maybe try the console logging version of hip (hip-debug), available here: https://github.com/koobo/HippoPlayer/tree/master/dist
Maybe the log output reveals something interesting.

[vulture]

Tried to play an AY file and I get "vgm2wav couldn't start, init error?" message.

I've tried both 020 and 020fpu versions in both c: and HP's dir. Tried both os 3.1 and 3.2 queue-handlers just in case. MHI is disabled.

Any idea what may cause this?

Thx!

[koobo]

Originally Posted by vulture

Tried to play an AY file and I get "vgm2wav couldn't start, init error?" message.

I've tried both 020 and 020fpu versions in both c: and HP's dir. Tried both os 3.1 and 3.2 queue-handlers just in case. MHI is disabled.

Any idea what may cause this?

For really short tunes (0-4 seconds) they start and get played through too fast for Hippo to notice, this leads to the above error at least. Was the AY tune a super short one? Some AY tunes are also unsupported by vgm2wav, this might be another reason for the same error message.

Have you checked with SnoopDos what happens?

[vulture]

@koobo

Thx for the reply

I tried NavySeals.ay and Switchblade.ay , both kinda long tunes. Yes, checked with snoopdos and had some fails with the newest queue handler and I reverted to the old. That fixed those fails, but the same message came up. Would it be useful if I send you those tunes to check them out?

[koobo]

Originally Posted by vulture

@koobo

I tried NavySeals.ay and Switchblade.ay , both kinda long tunes. Yes, checked with snoopdos and had some fails with the newest queue handler and I reverted to the old. That fixed those fails, but the same message came up. Would it be useful if I send you those tunes to check them out?

Sure, I can have look. I suspect vgm2wav incompatibility though, I have one "NavySeals.ay" which doesn't play, but the "SwitchBlade.ay" I have works ok.

[Estrayk]

Hello, koobo. I looove the xmaplay from 8bitbubsy integrated in Hippo, but I would like if possible to give it "AHI" support, or at least stereo support. The player is perfect and doesn't miss a single command or note, finetunes, everything is perfect, but the differences of listening to an .xm with the stereo vol-pans is too much. Would it be possible?

I leave you a video with three random .xm so you can listen yourself the differences.

Thank you very much.

[ Show youtube player ]

[patrik]

Originally Posted by vulture

@koobo

Thx for the reply

I tried NavySeals.ay and Switchblade.ay , both kinda long tunes. Yes, checked with snoopdos and had some fails with the newest queue handler and I reverted to the old. That fixed those fails, but the same message came up. Would it be useful if I send you those tunes to check them out?

What was the issue with the newest queue-handler? Is it reproducible and if so, what are the steps required? Please also provide the output of a “version full” on the queue-handler in question.