After the PC donation..., Things to come Options

[Frank Klemm]

Hi Folk,

I started migration of data from the old PC to the new one.
This was a little bit a pain, because the system hard disk is nearly
dead (but after some tries I got all data) and I had some stability
issues (the Iomega ZIP drive was the "guilty"), so the copying
stopped from time to time.

This evening I start to sort the data, most (65%) are Audio data
spreaded over all hard disks, other data are some Video data, Images
and Archive data (downloaded and sorted data from the Internet).
I hope the remaining data is less than 4.7 GByte, so I can make a
DVD-backup before continuing sorting.

But this is all straight forward, because of the plenty of hard disk
space. No "tower of hanoi" game.

E-Mail and Web access will then follow. Most difficult will be
the migration of the "1000 little modifications" of the system.
A small program there and there.


The first Musepack related work will be:
- mppenc 1.2 (1.15r + some small additions + bugfixes)
- mppdec 1.96 (1.95z1 + some small additions + bugfixes)
- replaygain 0.89 (support of different sample frequencies than 44.1 kHz, better API, modified application notes)

It follows the file format SV 7.5. Format freezing. Huffman table freezing.
libmpcdec.lib. New, modular decoder.

This post has been edited by Frank Klemm: Mar 27 2004, 20:37

[atici]

Is it also possible to make the sources as much platform independent as possible? This would be useful for building binaries by Intel C compiler and XScale, IA-64, PPC support... Maybe someday I could run a decoder on an XScale based Palm device.

I don't know how much source code optimizations in assembly are involved and how difficult this would be. But this would also ensure that MPC will be available on dominant platforms in the long term.

Thanks Frank.

Edit: By the way, maybe we should move the new improvement plans to another thread and keep this thread for pictures. The PC is built and the thread achieved its mission

This post has been edited by atici: Mar 27 2004, 20:59

[seanyseansean]

Frank,

Nice to see you

Anyways, I don't know how much work you want to do, but could you possibly (along with Christian) come up with work for others to do? There's a lot of experience here, and a lot of people who would love to help out, whether that be with testing, porting, or whatever.

[CiTay]

By the way, maybe we should move the new improvement plans to another thread and keep this thread for pictures. The PC is built and the thread achieved its mission

Yes, split from Donation for Frank Klemm's new PC. Comments about the PC can go there, comments about things to come can now go here.

[robUx4]

Is it also possible to make the sources as much platform independent as possible? This would be useful for building binaries by Intel C compiler and XScale, IA-64, PPC support... Maybe someday I could run a decoder on an XScale based Palm device.

I'm already working on this (ok, very slowly). I already make the decoder work under OS X in CVS. I'll work on the encoder tomorrow. Dibrom has some modified code that works but has not provided me with it yet.
I don't have the other compilers though, no Intel at least. But the targets for me are MSCV6, MSVC7 and GCC3.2+. It should work fine with older GCC too. And I think Frank uses a Watcom compiler ?

edit: missing Dibrom's code

This post has been edited by robUx4: Mar 27 2004, 23:18

[caligae]

Is it also possible to make the sources as much platform independent as possible? This would be useful for building binaries by Intel C compiler and XScale, IA-64, PPC support... Maybe someday I could run a decoder on an XScale based Palm device.

mppdec works on amd64 with minor modification to Makefile. Don't know about ppc.

[atici]

mppdec works on amd64 with minor modification to Makefile. Don't know about ppc.

AMD64 is 64 bit x86 so this is not surprising.

@robUx4: In case you're interested in a PalmOS port, the pocket-tunes player developers are quite approachable for plug-in support. Check my recent correspondence here.

Although such issues naturally have lower priority on the to-do list, it would bring an end to the "MPC is not/will never be supported on any portable device" argument. If something is not supported it's mostly due to the platform being closed (it's not MPC developers fault).

This post has been edited by atici: Mar 28 2004, 03:28

[xmixahlx]

amazing

all the small-step advancements are exciting!

some comments:

darin did some work for 1.15r building on OSX. is there anything he can include here? patch the 1.15r-current tree perhaps (if he has made modifications, i dunno, he was sorta cryptic about it)

1.95z67 builds as SV 15.15

is the plan to move mppdec+mppenc to: musepack (encoder/decoder frontend) + libmusepack (library) ?

could 16bit/32bit/dither/etc. support be added into musepack as switched parameters instead of static builds?

alsa support?

and what will be the "official" linux compiler/switches/config/buildprocess?

(so the real comment above is that i think the build process should be revamped for gcc3.2/3.3/3.4+automake,etc)


all i can think of atm
later

and welcome back frank

[caligae]

mppdec works on amd64 with minor modification to Makefile. Don't know about ppc.

AMD64 is 64 bit x86 so this is not surprising.

It's not that easy. There's lot of software that fails because programmers assume wrong pointer sizes and so on. Unfortunately you can't say generally that software that runs on 32Bit x86 will also run on 64Bit x86.

Two more findings:
I just tried it on alpha which works flawlessly too.

ppc works basically but has a flaw. The output is big endian. If you treat the output wave as signed be it sounds fine again.

The version I tested is mppdec-1.1 from Klemm's homepage.

[robUx4]

amazing

all the small-step advancements are exciting!

some comments:

darin did some work for 1.15r building on OSX. is there anything he can include here?  patch the 1.15r-current tree perhaps (if he has made modifications, i dunno, he was sorta cryptic about it)

1.95z67 builds as SV 15.15

is the plan to move mppdec+mppenc to: musepack (encoder/decoder frontend) + libmusepack (library) ?

could 16bit/32bit/dither/etc. support be added into musepack as switched parameters instead of static builds?

alsa support?

and what will be the "official" linux compiler/switches/config/buildprocess?

(so the real comment above is that i think the build process should be revamped for gcc3.2/3.3/3.4+automake,etc)

speaking for myself (ie not Frank) I'm not willing to use automake/autoconf. But gcc 3.2+ is probably the one that should be used now. At least for binary distributions.

I don't know when exactly the libmpc will be done (see Frank's post) but that's one of the main goal, so that MPC can be integrated in a wide variety of platform. (Even portable ones )

Should I contact Darin, or he's floating around here ?

If ALSA is also working under OS X (fink) it might be a good move from ESD because now ALSA is in the linux kernel.

For the rest, I don't know.

[seanyseansean]

Is it also possible to make the sources as much platform independent as possible? This would be useful for building binaries by Intel C compiler and XScale, IA-64, PPC support... Maybe someday I could run a decoder on an XScale based Palm device.

mppdec works on amd64 with minor modification to Makefile. Don't know about ppc.

By 'works', do you mean as a 32bit or 64bit compile?

[caligae]

speaking for myself (ie not Frank) I'm not willing to use automake/autoconf. But gcc 3.2+ is probably the one that should be used now. At least for binary distributions.

Autotoolify mppdec shouldn't be too much work. It's only one binary and has two libraries as dependency.

On the other hand there wouldn't be much benefit over not using autotools either.

[caligae]

mppdec works on amd64 with minor modification to Makefile. Don't know about ppc.

By 'works', do you mean as a 32bit or 64bit compile?

I was using a native 64 bit build.

[jtclipper]

I would like to see one binary ( enc & dec ).
I would also like to see correct support for pipelines.

[robUx4]

I would like to see one binary ( enc & dec ).
I would also like to see correct support for pipelines.

What would be the benefit of one binary only ?

[rjamorim]

Should I contact Darin, or he's floating around here ?

Darin = Dibrom

[robUx4]

OK
Anyway I fixed the endianess problems and now the encoder and decoder in CVS work under MSVC and OS X (should be OK with any GCC under Windows & Linux too).

I'll commit the XCode project too and then maybe the whole binary bunch (encoder and decoder for each OS from the code in CVS).

[caligae]

OK
Anyway I fixed the endianess problems and now the encoder and decoder in CVS work under MSVC and OS X (should be OK with any GCC under Windows & Linux too).

I'll commit the XCode project too and then maybe the whole binary bunch (encoder and decoder for each OS from the code in CVS).

Nice, this fixed the endianess problem here too.

For each os out there? Don't forget that every platform/os combination needs its own binary - have fun!

[jtclipper]

I would like to see one binary ( enc & dec ).
I would also like to see correct support for pipelines.

What would be the benefit of one binary only ?

For mp3 I use lame.exe for both without having to shuffle around with a lot of executables.
Why did the developers of LAME put them together? , I think it is better to have a single binary and I believe that both the encoder and the decoder use some shared code.
Also lame.exe behaves very nicely with pipelines ( | ) and stdin stdout the great majority of mpc binaries have problems with that.

[Canar]

Also lame.exe behaves very nicely with pipelines ( | ) and stdin stdout the great majority of mpc binaries have problems with that.

mppenc for Windows uses pipes perfectly for encoding. I use it all the time with foobar's CLI encoder.

I dunno if mppdec is worse, but I've never had a problem with mppenc.

I personally prefer the two separated binaries. Each performs a task well. Throwing them both into a single executable means that everytime you want to decode or encode, there's another switch you have to place on the commandline. It would also mess backwards-compatibility up badly.

[Thinky]

AFAIK, some of the newer mppdec versions (1.9[...]) had a bug that broke pipe support.

This post has been edited by Thinky: Mar 28 2004, 19:46

[Frank Klemm]

AFAIK, some of the newer mppdec versions (1.9[...]) had a bug that broke pipe support.

What *EXACTLY* do not work?

"Maschina nje rabotajet" do not work as error description.

IIRC I've changed some code to support PCM files in mppenc (Encoder!)
to support PCM files between 2 and 4 GByte with tags, but the pipe
code of mppdec should be from very early days.

Please additional respond via board E-Mail system.

This post has been edited by Frank Klemm: Mar 29 2004, 12:53

[danchr]

Is it also possible to make the sources as much platform independent as possible? This would be useful for building binaries by Intel C compiler and XScale, IA-64, PPC support...

MPC is pretty much cross platform. IIRC the changes needed to make it compile on Mac OS X were fairly straight forward, so porting it to another platform or processor shouldn't be too difficult.

If ALSA is also working under OS X (fink) it might be a good move from ESD because now ALSA is in the linux kernel.

ALSA stands for Advanced Linux Sound Architecture, and is pretty much Linux only. The Mac OS X equivalent would be CoreAudio - which uses an entirely different API. Not even OSS is available for Mac OS X, so it's either ESD or Arts - and Arts doesn't work all that well.

[robUx4]

Then I would suggest using PortAudio instead of all these APIs. It works under Windows, UNIX, Apple, BeOS, etc. The API is very simple and easy to use.

[Frank Klemm]

Also lame.exe behaves very nicely with pipelines ( | ) and stdin stdout the great majority of mpc binaries have problems with that.

Still the old question:

What *EXACTLY* do not work?