IPB

Welcome Guest ( Log In | Register )

3 Pages V   1 2 3 >  
Reply to this topicStart new topic
After the PC donation..., Things to come
Frank Klemm
post Mar 27 2004, 20:36
Post #1


MPC Developer


Group: Developer
Posts: 543
Joined: 15-December 01
From: Germany
Member No.: 659



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


--------------------
-- Frank Klemm
Go to the top of the page
+Quote Post
atici
post Mar 27 2004, 20:53
Post #2





Group: Members (Donating)
Posts: 1180
Joined: 21-February 02
From: Chicago
Member No.: 1367



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 biggrin.gif

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


--------------------
The object of mankind lies in its highest individuals.
One must have chaos in oneself to be able to give birth to a dancing star.
Go to the top of the page
+Quote Post
seanyseansean
post Mar 27 2004, 21:17
Post #3





Group: Members (Donating)
Posts: 487
Joined: 12-August 02
From: Cheltenham, UK
Member No.: 3029



Frank,

Nice to see you smile.gif

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.
Go to the top of the page
+Quote Post
CiTay
post Mar 27 2004, 21:42
Post #4


Administrator


Group: Admin
Posts: 2378
Joined: 22-September 01
Member No.: 3



QUOTE (atici @ Mar 27 2004, 08:53 PM)
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 biggrin.gif

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. smile.gif
Go to the top of the page
+Quote Post
robUx4
post Mar 27 2004, 23:16
Post #5


Matroska Developer


Group: Developer (Donating)
Posts: 410
Joined: 14-March 02
From: Paris
Member No.: 1519



QUOTE (atici @ Mar 27 2004, 08:53 PM)
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


--------------------
http://www.matroska.org/ : the best vapourware / http://robux4.blogspot.com/
Go to the top of the page
+Quote Post
caligae
post Mar 28 2004, 00:28
Post #6





Group: Members
Posts: 186
Joined: 23-January 02
Member No.: 1132



QUOTE (atici @ Mar 27 2004, 09:53 PM)
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.
Go to the top of the page
+Quote Post
atici
post Mar 28 2004, 03:20
Post #7





Group: Members (Donating)
Posts: 1180
Joined: 21-February 02
From: Chicago
Member No.: 1367



QUOTE
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


--------------------
The object of mankind lies in its highest individuals.
One must have chaos in oneself to be able to give birth to a dancing star.
Go to the top of the page
+Quote Post
xmixahlx
post Mar 28 2004, 08:41
Post #8





Group: Members
Posts: 1394
Joined: 20-December 01
From: seattle
Member No.: 693



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 wink.gif


--------------------
RareWares/Debian :: http://www.rarewares.org/debian.html
Go to the top of the page
+Quote Post
caligae
post Mar 28 2004, 09:29
Post #9





Group: Members
Posts: 186
Joined: 23-January 02
Member No.: 1132



QUOTE (atici @ Mar 28 2004, 04:20 AM)
QUOTE
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.
Go to the top of the page
+Quote Post
robUx4
post Mar 28 2004, 10:30
Post #10


Matroska Developer


Group: Developer (Donating)
Posts: 410
Joined: 14-March 02
From: Paris
Member No.: 1519



QUOTE (xmixahlx @ Mar 28 2004, 08:41 AM)
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 wink.gif)

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.


--------------------
http://www.matroska.org/ : the best vapourware / http://robux4.blogspot.com/
Go to the top of the page
+Quote Post
seanyseansean
post Mar 28 2004, 10:43
Post #11





Group: Members (Donating)
Posts: 487
Joined: 12-August 02
From: Cheltenham, UK
Member No.: 3029



QUOTE (caligae @ Mar 27 2004, 11:28 PM)
QUOTE (atici @ Mar 27 2004, 09:53 PM)
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?
Go to the top of the page
+Quote Post
caligae
post Mar 28 2004, 10:47
Post #12





Group: Members
Posts: 186
Joined: 23-January 02
Member No.: 1132



QUOTE (robUx4 @ Mar 28 2004, 11:30 AM)
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.
Go to the top of the page
+Quote Post
caligae
post Mar 28 2004, 10:57
Post #13





Group: Members
Posts: 186
Joined: 23-January 02
Member No.: 1132



QUOTE (seanyseansean @ Mar 28 2004, 11:43 AM)
QUOTE (caligae @ Mar 27 2004, 11:28 PM)
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.
Go to the top of the page
+Quote Post
jtclipper
post Mar 28 2004, 13:08
Post #14





Group: Members
Posts: 256
Joined: 25-May 03
From: Greece
Member No.: 6805



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


--------------------
Dimitris
Go to the top of the page
+Quote Post
robUx4
post Mar 28 2004, 13:50
Post #15


Matroska Developer


Group: Developer (Donating)
Posts: 410
Joined: 14-March 02
From: Paris
Member No.: 1519



QUOTE (jtclipper @ Mar 28 2004, 01:08 PM)
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 ?


--------------------
http://www.matroska.org/ : the best vapourware / http://robux4.blogspot.com/
Go to the top of the page
+Quote Post
rjamorim
post Mar 28 2004, 14:24
Post #16


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



QUOTE (robUx4 @ Mar 28 2004, 06:30 AM)
Should I contact Darin, or he's floating around here ?

Darin = Dibrom


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
robUx4
post Mar 28 2004, 16:33
Post #17


Matroska Developer


Group: Developer (Donating)
Posts: 410
Joined: 14-March 02
From: Paris
Member No.: 1519



OK smile.gif
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).


--------------------
http://www.matroska.org/ : the best vapourware / http://robux4.blogspot.com/
Go to the top of the page
+Quote Post
caligae
post Mar 28 2004, 17:23
Post #18





Group: Members
Posts: 186
Joined: 23-January 02
Member No.: 1132



QUOTE (robUx4 @ Mar 28 2004, 05:33 PM)
OK smile.gif
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! smile.gif
Go to the top of the page
+Quote Post
jtclipper
post Mar 28 2004, 17:37
Post #19





Group: Members
Posts: 256
Joined: 25-May 03
From: Greece
Member No.: 6805



QUOTE (robUx4 @ Mar 28 2004, 04:50 AM)
QUOTE (jtclipper @ Mar 28 2004, 01:08 PM)
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.


--------------------
Dimitris
Go to the top of the page
+Quote Post
Canar
post Mar 28 2004, 18:56
Post #20





Group: Super Moderator
Posts: 3361
Joined: 26-July 02
From: princegeorge.ca
Member No.: 2796



QUOTE (jtclipper @ Mar 28 2004, 08:37 AM)
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.


--------------------
You cannot ABX the rustling of jimmies.
No mouse? No problem.
Go to the top of the page
+Quote Post
Thinky
post Mar 28 2004, 19:17
Post #21





Group: Members
Posts: 23
Joined: 9-July 02
From: Germany
Member No.: 2537



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
Go to the top of the page
+Quote Post
Frank Klemm
post Mar 29 2004, 12:50
Post #22


MPC Developer


Group: Developer
Posts: 543
Joined: 15-December 01
From: Germany
Member No.: 659



QUOTE (Thinky @ Mar 28 2004, 08:17 PM)
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


--------------------
-- Frank Klemm
Go to the top of the page
+Quote Post
danchr
post Mar 29 2004, 13:42
Post #23





Group: Members
Posts: 487
Joined: 6-April 03
From: Århus, Denmark
Member No.: 5861



QUOTE (atici @ Mar 27 2004, 08:53 PM)
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.
QUOTE (robUx4 @ Mar 28 2004, 10:30 AM)
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.
Go to the top of the page
+Quote Post
robUx4
post Mar 29 2004, 15:21
Post #24


Matroska Developer


Group: Developer (Donating)
Posts: 410
Joined: 14-March 02
From: Paris
Member No.: 1519



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.


--------------------
http://www.matroska.org/ : the best vapourware / http://robux4.blogspot.com/
Go to the top of the page
+Quote Post
Frank Klemm
post Mar 29 2004, 15:26
Post #25


MPC Developer


Group: Developer
Posts: 543
Joined: 15-December 01
From: Germany
Member No.: 659



QUOTE
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?


--------------------
-- Frank Klemm
Go to the top of the page
+Quote Post

3 Pages V   1 2 3 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 22nd September 2014 - 23:20