MP3 on a 68000 Amiga

[gulliver]

I understand that playing an mp3 with a 68000 Amiga sounds unreasonably mad.

But in this age of fast FPGAs and Minimig reimplementations, not to mention todays insanely fast 68000 accelerators, wouldnt it be reasonable to have a software mp3 playback solution for 68000?

For starters mpega.library seems to be coded for 68020 and up, is there someone willing to recompile it for a plain 68000?

[Retrofan]

You can use a MAS player with a 68000 http://amigakit.leamancomputing.com/...oducts_id=1078

[gulliver]

I was talking about a software solution, not a hardware based one.

[Retrofan]

Ok. Answer: But that's impossible to run without a FPGA accelerator (hardware too) or WinUAE emulation. Do you want it only to work under emulation?

[gulliver]

Simple answer: we have the Chamaleon, MiST, FPGAArcade, Minimig, etc that are all 68000 capable and pretty fast (and all have problems with 68020 cores).

The same goes with Amiga accelerators: we have the Vampire, and there seems to be a handfull of nice and insanely fast, 68000 accelerator projects going on.

So the word impossible is not the right one. There is lot of 68000 hardware that would benefit from it.

[Daedalus]

There's no reason why it can't be done, but given that mpega.library etc. are optimised for the 020+, there's probably a fair bit of work involved in making it 68000 compatible so it would be more than a simple recompile. But if 68000-alike machines appear and are fast enough to benefit, I'm sure someone will make it happen. Just bear in mind that an 060 was required to play reasonable quality MP3s properly, so you'll need a 68000 solution capable of matching that speed (75 MIPS) which would mean an accelerator equivalent to a 68000 running at around 500MHz. I'm not sure whether the FPGA solutions have reached that yet, but I'm sure they will given time.

[pandy71]

Originally Posted by gulliver

I was talking about a software solution, not a hardware based one.

Nope - you talking about HW solution (or trough software that run on specialized HW or on accelerator).
To decode MP3 you need somewhere usually between 10 - 30MIPS (depend on CPU/system architecture).

[gulliver]

Many Amiga users have played mp3 (and made youtube videos about it) with just 10 MIPS (68030 at 50Mhz), of course, with not the best of qualities. But it indeed works. As an example, the MiST Amiga core goes beyond 10 MIPS, the same happens with the FPGAArcade, so they are ready to go.

[Thorham]

WAV is much better.

[gulliver]

Originally Posted by Thorham

WAV is much better.

Not really, as it occupies a lot of HDD space and keeps the disk interface pretty busy. It is much better in that it requires less cpu resources. But then the average computer user moved to mp3 long ago, and for a good reason.

[matthey]

Originally Posted by gulliver

Many Amiga users have played mp3 (and made youtube videos about it) with just 10 MIPS (68030 at 50Mhz), of course, with not the best of qualities. But it indeed works. As an example, the MiST Amiga core goes beyond 10 MIPS, the same happens with the FPGAArcade, so they are ready to go.

Both Mist and FPGA Arcade have 68020 cores. Meynaf's 68020 mpega.library probably uses a minimum of double memory indirect addressing modes and bitfield instructions which could cause problems but should still benefit from more common 68020 ISA enhancements providing a performance increase and better code density. Compiling with vbcc for the 68020 or above avoids most double memory indirect addressing modes and bitfield instructions as well. The 68020 ISA provides some very nice features including misaligned addressing support, index register scaling, long branches and wider multiply and divide besides the less common problematic stuff. It should be possible to compile C code for the 68000 but it will be slow without 68020 or assembler enhancements. The best solution is to debug these "supposedly" 68020 compatible cores.

[Thorham]

Originally Posted by gulliver

Not really, as it occupies a lot of HDD space

Who cares? I have an enormous amount of space on my Amiga hard disk, and the only data that's large that is actually usable is audio data.

Originally Posted by gulliver

and keeps the disk interface pretty busy.

28 Khz 16 bit stereo WAVs use up 112Kb of bandwidth per second. That's not busy.

Originally Posted by gulliver

It is much better in that it requires less cpu resources.

Exactly, especially important when you want good quality on an Amiga with a 50 mhz 68030.

Originally Posted by gulliver

But then the average computer user moved to mp3 long ago, and for a good reason.

Yeah, but we're not exactly average computer users, are we?

Bottom line: WAV is best for computers with 68K CPUs with a large hard disk. Native would actually be even better, but what outputs native Amiga 14 bit audio?

[GhstWlf]

If I remember correctly, one of the u-law or a-law codecs outputs 14-bit samples. It also compresses the sound a bit.

Edit: u-law has 14-bit samples, a-law has 13-bit samples Wikipedia on G.711 standard

[Thorham]

Originally Posted by GhstWlf

If I remember correctly, one of the u-law or a-law codecs outputs 14-bit samples. It also compresses the sound a bit.

Edit: u-law has 14-bit samples, a-law has 13-bit samples Wikipedia on G.711 standard

The sample rate is only 8000 hertz, though. You'd also have to hope something actually plays it, preferably Hippoplayer or Delitracker.

[Retrofan]

Certainly the mp3 offers better sizes. For example I've got some mp3 songs converted to aiff (another nice format for the amiga) and while "Whodini -I need a break" takes 53,5Mb for aiff, it only takes 12,1Mb for mp3.

[alexh]

Install a server on your NAS / PC with an MP3->WAV converter? Stream to the amiga over ethernet?

[daxb]

Of course it depends on what do you want/have and how to handle. In the `90 mp3 was usefull because of limited available drive space. From `00 on that doesn`t matter. Without loss of quality you need 060 cpu. On 040/40 you have to reduce qualtity nevertheless with 100% cpu usage. With 030 it doesn`t become better. So, if you really need a 500 MHz 68000 then I doubt that it is useful.

Using wav/aiff/... works already and at least an accelerated 68000 should be fast enough to play it from HD. Filesize could be an issue but that depends on how often do you move it around and the used system.

Overall, I guess it isn`t worth the effort if you have alternatives. Modern FPGA stuff should at least have 020+ core. IMHO it makes more sense to have a super fast 020/040/060 then a super fast 68000.

[GhstWlf]

Originally Posted by Thorham

The sample rate is only 8000 hertz, though. You'd also have to hope something actually plays it, preferably Hippoplayer or Delitracker.

A-law and U-law is compression on the dynamic range not time or frequency. The compression is applied on every sample individually.
That means that they can have any sample rate you want, as long as the playback software/hardware can handle it.

[GhstWlf]

Originally Posted by gulliver

I understand that playing an mp3 with a 68000 Amiga sounds unreasonably mad.

But in this age of fast FPGAs and Minimig reimplementations, not to mention todays insanely fast 68000 accelerators, wouldnt it be reasonable to have a software mp3 playback solution for 68000?

For starters mpega.library seems to be coded for 68020 and up, is there someone willing to recompile it for a plain 68000?

What are you going to use it for? Play your mp3s or develop some software?

[gulliver]

Originally Posted by GhstWlf

What are you going to use it for? Play your mp3s or develop some software?

To play mp3. There are couple of Amiga sound players that could work with a 68000 if just mpega.library was available for 68000.

I am okay anyway if someone wants to build a new player for 68000 altogether (one that doesnt require mpega.library), but this route is probably more unlikely to occur. It is just that mpega.library widens up the possibilities for both devs and users.

Of course it would be better if fpga 68020 cores out there worked, but reality is that they still fail here and there, which prevents them to be stable enough for daily usage. On the contrary, 68000 cores are rock steady.