[meynaf]

Originally Posted by Thorham

And it's so obvious that it get's looked over way to easily It also helps that I never use lea...

I find this strange. Even though there are insns that are not useful, lea isn't among them !

Originally Posted by Thorham

Great Can it be downloaded already? I really want look at this.

Well, it wasn't by the time you posted, but now it can (see attached file).

Originally Posted by Thorham

That's impressive, but with 240 gig of hd space not really needed

Of course, if you see things like that ;-)

Originally Posted by Thorham

Oh no, they use the cpu to read a register Man, that sucks. I thought the data was dmaed (new word) to chipmem. That would at least allow data that needs to be in chipmem to be transferred there directly. Pity

This is cheap solution. Using dma would require to add a new dma channel.
Also, HD back in 1992 weren't fast enough to push this system to its limits.

Originally Posted by Thorham

Of course, but it would probably be more expensive as well. Besides, such a fast 68k cpu wouldn't be much fun, no challenge

Not more expensive if it finally takes over like x86 did. Probably cheaper in fact, because of simpler architecture. You just need equal sales volume.

About the challenge, there can still be some. If it's not making it faster, could be making it smaller. Or make enormous computations (such as video encoding or world simulations) run faster

Originally Posted by Thorham

To me, trying is part of the fun.

I have some fun in store for you then

Originally Posted by Thorham

Okay, but does anyone actually use it? Everyone encodes music in mp3, ogg, etc these days. It would be a waste of time to optimize code that won't be used. It seems a lot better to get the mp3 part to be as fast as possible.

This is what I'm doing, actually. Other layers are a remote todo list

Originally Posted by Thorham

That depends on the coders commenting skills

I want to see yours then

Originally Posted by Thorham

Yes, but not everything. Having big blocks of code without spaces in between a few lines here and there makes it harder to read.

That depends on the coders reading skills

Originally Posted by Thorham

Perhaps, perhaps not. I don't write in C often, and as such my C coding style is probably less then optimal.

IMO the worse coding style is the most frequently used one...

Originally Posted by Thorham

And be much easier to read, I bet

Unsure. More lines in overall means less meaningful lines on actual view.

Originally Posted by Thorham

It's been 'fun' so far... Man, what a big one

Yeah, that sure is big, but there are bigger ones.

Originally Posted by Thorham

I tried the library itself. The problem was that I thought I had to reset to get the new library to work after testing the original, witch made me think that trying things would suck. D'oh. I had totally forgotten about flushlibs.

Anyway, since the problem is solved... I tried it with Delitracker, and although it produces a nice stream of continuous audio, the quality was quite bad, witch is sadly due to Delitracker. Why on earth does Delitracker only use the 14bit genie when you turn on mixing? It only reduces the quality level. 14Bit replay is DMA, and doesn't need mixing.

Don't turn on mixing, it's useless and just wastes time (and it won't use 14bit genie). Also don't use AHI, or quality will decrease (but then you deserved it) !

Originally Posted by Thorham

As for your optimizing effort, top notch I tried the same high quality mp3 with Hippoplayer (quality 0, frequency devision 2) in 14 bit, and it sounded fantastic. Now you know the audio isn't continuous, of course, some of the buffer is replayed, but... the replay length is short, much better than the original.

I think that it may be possible to actually get this to work properly. In fact, seeing how dreadful the quality is with Delitracker, why not take shortcuts such as the ones I proposed for your jpeg decoder? In this case, the audio will still sound much better than with Deli, so throwing some quality away won't really matter. Can't hurt to try.

If DT2 is dreadful on your machine, then there's something wrong with your setup...
Besides, if it's really dreadful, then it's not DT but its mpegaplayer plugin.

Or... Are you SURE it wasn't one of your lossy tests which got used ?
I forgot to tell you that doing a lib flush isn't enough : you must also eject the mpega player before ! (open the players window and click on "clear" to do this quickly)

Or... Are you playing something with settings just too high ? If so, it'll sound bad but it's just because there are small "holes" in the replay. If you check "mono" the quality will be normal. Playing with settings your cpu can't handle is looking for bad quality

Originally Posted by Thorham

Then do it in the way I proposed earlier. Really easy to write then, and if it doesn't work properly, you haven't wasted much time. Give it a shot.

You mean calling the external player ? Well, ok, but it's for when I have something new to test.

Originally Posted by Thorham

In my opinion, yes. No one uses mp1 and mp2, in fact, do mp3 players even support it? Unlikely, so just get rid of it, it's a waste of time.

For now I prefer to just leave them alone.

Originally Posted by Thorham

Do it in the ram disk. Further more, if you're willing to wait 30 seconds to decode a short piece of audio to ram, then it probably won't matter much. Just try it before you take the complex route.

It's worth trying (if I have something new to actually test), even though I prefer to have timings up to the frame even for 30 seconds...

Originally Posted by Thorham

If you agree that taking decoding short cuts might work, then sure, if not, you're going to have to wait until I see something, this is code is quite tough.

Such short cuts are for low, perhaps medium, qualities only. Not for high, and high is the goal.

Originally Posted by Thorham

It's just simple in cases where you need multiple instructions to do a mul, there you can just use a mul on '060, as far as I know.

Sometimes the mul just can't be avoided... and then you're happy when you have a 060 !

Originally Posted by Thorham

Then it's time to squeeze your brain more Start by using Hippo in 14 bit (not with ahi, of course), and use the settings I wrote above. Try to sacrifice quality in the decoding process, while keeping the audio quality better than what Deli gives us.

But Deli doesn't give worse quality than Hippo...

Originally Posted by Thorham

Didn't spot it. Anyway, if it's executed in a loop, directly, or indirectly, it has to go. All instructions that don't have to be there should be removed.

There aren't many now, apart in the not time critical parts.

Originally Posted by Thorham

When I decoded some good quality mp3s to wav in the highest quality settings, the audio sounded fantastic. As said, I've tried your version with the Delitracker you supplied, and Deli made it sound bloody awefull. It sounds great with Hippo, and I'm sure it sounds just as good as the original when using the highest settings. It's not your version that's the problem, its Delitracker.

Perhaps it's just that 14 bit calibration problem again. I have no trouble with DT.
Didn't you try DT after your lossy tests ? I suspect this version wasn't used by Hippo (perhaps it holds the lib permanently) but later used by DT !

Originally Posted by Thorham

Get a better player, meynaf

There are none.

Btw if you really think it's crap when playing MP3, I have resourced the player too. But it's not that. Quality on DT is same as decoded wave and if it's not the case for you there's something wrong and it's not DT itself.