Hydrogenaudio Forums > lossyWAV Development

Nick.C

May 10 2008, 03:57

QUOTE(collector @ May 10 2008, 09:40)

QUOTE(Nick.C @ May 8 2008, 09:56)

A progress bar in what sense and to what purpose? I suppose I could append a line to a log file with a "-l <filepath\filename>" type parameter but what would you want it to contain? When running from the command line there is a progress output of sorts which doesn't include the %age complete, rather amount of data processed (duration of WAV file processed) and number of bits removed so far.
A bit more detail as to what you would want to see would be nice.

A progress %age would be more convenient to me while working with dos-screen-output and batchfiles than the up- and downcounting to just 256 MB. When processing a disc image of say 771 MB, it's useless to see the up and downcounting not knowing where it ends. The percentage like flac does is fine.
And while processing I see an 'average' line with info that I would like to save. I'm a list and reports man. Especially in the testperiods it's nice to see what lossywav did with my files. I know most people us xp and foobar, but I'm with win98 on a slower and older computer, which is sufficient for playing my music and surfing.

Thanks for the additional information - I didn't realise that the size was overflowing - will be fixed. As I know the size of the WAV file, it is trivial to put in %age complete. I'll see what I can to to help with the final stats line that you want to save....

jesseg

May 10 2008, 08:23

The only thing I could see a percentage being useful for is if someone wants to send that information back into a progress bar in a front-end. But then... it's probably just as easy for the person coding the front-end to convert the file size and file completed numbers to percentage... as it would be for Nick.C to do it on his end.

And yeah, either way it's only going to show the percentage for each file, NOT a batch job, cos lossyWAV doesn't know about your batch job.

Although it's much easier to do the same in C or ASM. I think OggdropXPd does this already, doesn't it?

Nick.C

May 11 2008, 01:40

QUOTE(collector @ May 10 2008, 09:40)

A progress %age would be more convenient to me while working with dos-screen-output and batchfiles than the up- and downcounting to just 256 MB. When processing a disc image of say 771 MB, it's useless to see the up and downcounting not knowing where it ends. The percentage like flac does is fine.
And while processing I see an 'average' line with info that I would like to save. I'm a list and reports man. Especially in the testperiods it's nice to see what lossywav did with my files. I know most people us xp and foobar, but I'm with win98 on a slower and older computer, which is sufficient for playing my music and surfing.

Okay, I've modified the MB counter and it shouldn't overflow - I'll test a large WAV file tonight.
A %age counter (x.xx%) has been added which should be enough resolution to see progress on an older computer / large file.
The "total bits removed / total codec blocks" detail has been removed as well.
I was toying with a "time already taken / total time to process completion" predictor - any use to anyone?

collector

May 11 2008, 03:43

QUOTE(Nick.C @ May 10 2008, 23:40)

Okay, I've modified the MB counter and it shouldn't overflow - I'll test a large WAV file tonight.
A %age counter (x.xx%) has been added which should be enough resolution to see progress on an older computer / large file.

Great.

No need for the decimals, but OK. It sounds good.

QUOTE

I was toying with a "time already taken / total time to process completion" predictor - any use to anyone?

Yep. To me. ETA is always nice to know for impatient people with slow machines. (You'll understand I won't use the -below, -low options..)

Nick.C

May 12 2008, 04:05

I think issuing lossyWAV under the GNU GPL and Copyleft will be better in the long run for the project, so that is my plan. Does the following look acceptable? I will be including a url to the current GNU GPL in the help as well as a copy of GPL.txt in the .zip distribution file, this is somewhat of a work in progress as I have never publicly released software before.

How do these look:

CODE

lossyWAV v1.0.0, Copyright (C) 2007,2008 Nick Currie. Copyleft.
Issued as free software; License: GNU GPL; Issued with NO WARRANTY WHATSOEVER.

Usage   : lossyWAV <input wav file> <options>

Example : lossyWAV musicfile.wav

Quality Options:

-q <n>        quality preset (10 = highest quality, 0 = lowest bitrate;
              -q 5 is generally accepted to be transparent) default = -q 5.

Standard Options:

-check        check if WAV file has already been processed; default=off.
              errorlevel=16 if already processed, 0 if not.
-correction   write correction file while processing WAV file; default=off.
-force        forcibly over-write output file if it exists; default=off.
-help         display help.
-longhelp     display extended help.
-merge        merge existing lossy.wav and lwcdf.wav files.
-noclips      set allowable number of clips per channel per codec block to 0;
              default: -q 0 to 3 = 3; -q 4 = 2; -q 5 = 1; -q 6 to 10 = 0.
-o <folder>   destination folder for the output file(s).

Special thanks:

David Robinson for the method itself and motivation to implement it.
Don Cross for the original Pascal source for the FFT algorithm used.
Horst Albrecht for valuable tuning input and feedback.

CODE

lossyWAV v1.0.0, Copyright (C) 2007,2008 Nick Currie. Copyleft.
Issued as free software; License: GNU GPL; Issued with NO WARRANTY WHATSOEVER.

Usage   : lossyWAV <input wav file> <options>

Example : lossyWAV musicfile.wav

Quality Options:

-q <n>        quality preset (10 = highest quality, 0 = lowest bitrate;
              -q 5 is generally accepted to be transparent) default = -q 5.

Standard Options:

-check        check if WAV file has already been processed; default=off.
              errorlevel=16 if already processed, 0 if not.
-correction   write correction file while processing WAV file; default=off.
-force        forcibly over-write output file if it exists; default=off.
-help         display help.
-longhelp     display extended help.
-merge        merge existing lossy.wav and lwcdf.wav files.
-noclips      set allowable number of clips per channel per codec block to 0;
              default: -q 0 to 3 = 3; -q 4 = 2; -q 5 = 1; -q 6 to 10 = 0.
-o <folder>   destination folder for the output file(s).

Advanced Options:

-analyses <n> select number of FFT analysis lengths to use; (2<=n<=5);
              default=2, i.e. 64 sample and 1024 sample FFT analyses;
              (3=2+128 sample FFT; 4=3+256 sample FFT; 5=4+512 sample FFT).
-fft32        enable 32 sample FFT for improved impulse detection;
              defaults: -q 0 to 2 = off; -q 3 to 10 = on.
-minbits <n>  select minimum bits to keep (0.0<=n<=8.0, resolution = 0.01);
              default = (2.9,2.95,3,3.125,3.25,3.375,3.5,3.625,3.75,3.875,4)
-scale <n>    scaling factor from WaveGain / etc; default = 1.000000; n<>0!

System Options:

-detail       enable detailed output mode
-nowarn       suppress lossyWAV warnings.
-quiet        significantly reduce screen output.

-below        set process priority to below normal.
-low          set process priority to low.

Special thanks:

David Robinson for the method itself and motivation to implement it.
Don Cross for the original Pascal source for the FFT algorithm used.
Horst Albrecht for valuable tuning input and feedback.

CODE

C:\Data_NIC\_WAV\WAV\tmp>lossywav ..\_swavyy\"Jean Michel Jarre - [1976] Oxygene.wav" -q 0 -force
lossyWAV v1.0.0, Copyright (C) 2007,2008 Nick Currie. Copyleft.
Issued as free software; License: GNU GPL; Issued with NO WARRANTY WHATSOEVER.
Processing : Jean Michel Jarre - [1976] Oxygene.wav
Format : 44.10kHz; 2 ch.; 16 bit.
Progress : 2.25%, 9.00MB, 4.7743 bits; 9.94x; 5.38s/239.56s;

CODE

C:\Data_NIC\_WAV\WAV\tmp>lossywav ..\_swavyy\"Jean Michel Jarre - [1976] Oxygene.wav" -q 0 -force
lossyWAV v1.0.0, Copyright (C) 2007,2008 Nick Currie. Copyleft.
Issued as free software; License: GNU GPL; Issued with NO WARRANTY WHATSOEVER.
Processing : Jean Michel Jarre - [1976] Oxygene.wav
Format : 44.10kHz; 2 ch.; 16 bit.
Average : 400.56MB; 6.3596 bits; 24.46x; 97.34s;
%lossyWAV Warning% : 6 sample(s) clipped to limiting amplitude.

CODE

C:\Data_NIC\_WAV\WAV\tmp>lossywav ..\_swavyy\"Jean Michel Jarre - [1976] Oxygene.wav" -q 0 -force -quiet -nowarn
Jean Michel Jarre - [1976] Oxygene.wav; 400.56MB; 6.3596; 23.24x; 102.47s; C:6;

Mitch 1 2

May 12 2008, 06:20

It looks alright to me.

Nick.C

May 12 2008, 06:30

QUOTE(Mitch 1 2 @ May 12 2008, 13:20)

It looks alright to me.

Thanks, Mitch.

Many thanks to Robert for the pointer to the GNU Coding Standards documentation. Does the following seem to more closely comply?

CODE

lossyWAV 1.0.0, Copyright (C) 2007,2008 Nick Currie. Copyleft.
Issued as free software; License: GNU GPL; Issued with NO WARRANTY WHATSOEVER.

Usage   : lossyWAV <input wav file> <options>

Example : lossyWAV musicfile.wav

Quality Options:

-q, --quality <n>   quality preset (10=highest quality, 0=lowest bitrate;
                    -q 5 is generally accepted to be transparent)
                    default=-q 5.

Standard Options:

-c, --check         check if WAV file has already been processed; default=off.
                    errorlevel=16 if already processed, 0 if not.
-C, --correction    write correction file for processed WAV file; default=off.
-f, --force         forcibly over-write output file if it exists; default=off.
-h, --help          display help.
-L, --longhelp      display extended help.
-M, --merge         merge existing lossy.wav and lwcdf.wav files.
-N, --noclips       set allowable number of clips / channel / codec block to 0;
                    default=3,3,3,3,2,1,0,0,0,0,0 (-q 0 to -q 10)
-o, --outdir <dir>  destination directory for the output file(s).
-v, --version       display the lossyWAV version number.

Advanced Options:

-a, --analyses <n>  select number of FFT analysis lengths to use; (2<=n<=5);
                    default=2, i.e. 64 sample and 1024 sample FFT analyses;
                    (3=+128 sample FFT; 4=+256 sample FFT; 5=+512 sample FFT).
-F, --fft32         enable 32 sample FFT for improved impulse detection;
                    defaults: -q 0 to 2=off; -q 3 to 10=on.
-m, --minbits <n>   select minimum bits to keep (0.00<=n<=8.00);
                    default=2.9,2.95,3,3.125,3.25,3.375,3.5,3.625,3.75,3.875,4.
-s, --scale <n>     scaling factor from WaveGain, etc; default=1.000000; n<>0!

System Options:

-d, --detail        enable detailed output mode
-n, --nowarnings    suppress lossyWAV warnings.
-Q, --quiet         significantly reduce screen output.

-b, --below         set process priority to below normal.
-l, --low           set process priority to low.

Special thanks:

David Robinson for the method itself and motivation to implement it.
Don Cross for the original Pascal source for the FFT algorithm used.
Horst Albrecht for valuable tuning input and feedback.

botface

May 12 2008, 08:12

Looks good to me

GeSomeone

May 12 2008, 10:12

QUOTE(Nick.C @ May 12 2008, 14:30)

lossyWAV 1.0.0

gasmann

May 12 2008, 13:09

Is stdin for encoding technically impossible? It would be great if one could live without these temporary files

Everything else is soo great! Thanks a lot!

Nick.C

May 12 2008, 13:14

QUOTE(gasmann @ May 12 2008, 20:09)

Is stdin for encoding technically impossible? It would be great if one could live without these temporary files

Everything else is soo great! Thanks a lot!

I don't think so, I've not tried it in Delphi.... I will certainly add it to the list for 1.1.0, along with noise shaping.

Nick.C

May 12 2008, 13:58

lossyWAV 1.0.0 released.

gasmann

May 13 2008, 01:42

well, since it's gpl'ed now, can you please make the sourcecode available to me? I want to look into an stdin 'hack'

thanks

Nick.C

May 13 2008, 01:45

QUOTE(gasmann @ May 13 2008, 08:42)

well, since it's gpl'ed now, can you please make the sourcecode available to me? I want to look into an stdin 'hack'

thanks

Yes - I will post the code in post #1 of this thread at lunchtime - I haven't yet added all of the GNU GPL / Copyleft related notices to all of the units. Currently amending the WAV chunk handling to deal properly with unrecognised chunks.

NB: Copyleft means you will have to share the hack

(i.e. save me the trouble of working it out for myself....

).

gasmann

May 13 2008, 04:48

Of course I will do that

But I can't promise anything... I'm still quite a beginner (but I own Delphi 6 because we need it at school), so please don't depend on it too much.

GeSomeone

May 13 2008, 06:08

It would be an excellent time to start a new thread when post 1.0 development will begin

Nick.C

May 13 2008, 06:20

QUOTE(gasmann @ May 13 2008, 11:48)

Of course I will do that

But I can't promise anything... I'm still quite a beginner (but I own Delphi 6 because we need it at school), so please don't depend on it too much.

I have found an "issue" with the --merge parameter for 24-bit files. I will post source as soon as this is amended. Thanks for your patience.

Nick.

@gesomeone: When I have "fixed" 1.0.0 with respect to the WAV chunk issue and the --merge issue, I will indeed start a new thread

.

SebastianG

May 13 2008, 08:35

This post is slightly off-topic.

QUOTE(Nick.C @ May 12 2008, 14:30)

[...] GNU Coding Standards documentation.

I took the chance to check it again. Granted, it sounds obvious that C is probably the "most used" programming language in the open source community and that you can count on more people willing to help with your C-program simply because there're more programmers capable of doing so. But I think it's not appropriate to apply the same policies to non-GNU software like lossyWAV. It would be "behind the times" to still advocate C over C++ for example. C++ became an ISO standard 10 years ago! There're plenty of good reasons why people should try to move on. RAII is just one example.

Sorry, but I just felt compelled to say this ...

edit: I think the previous comment needs some clarification. I realize that nobody has advocated the use a specific language for lossyWav and I also intend not to do so. It just expresses my personal opinion regarding pros and cons of C and C++ in general.

Cheers,
SG

Nick.C

May 13 2008, 15:58

lossyWAV 1.0.0b source released, see post #1 in this thread.

rbrito

Sep 16 2008, 16:42

QUOTE(Nick.C @ May 12 2008, 07:05)

I think issuing lossyWAV under the GNU GPL and Copyleft will be better in the long run for the project, so that is my plan.

This was a nice and welcome choice, I think. BTW, what about putting the code in a public repository, so that you can manage the changes? If you want some help with repositories, I think that I can help. This would ease a lot the development and release of the files and also allow the project to gain momentum.

Perhaps a project hosted on SourceForge or BerliOS, with a Subversion repository would be nice, as it would prevent loosing history of the files and directories. I see that you are mostly using it under Windows and don't know C.

I want to use lossyWAV on some of my bootlegs, since I am under severe space constraints. I want this so badly, but:

I don't know Windows very well (in fact, I don't even have a Windows machine).
I use primarily Unix systems, including Linux and FreeBSD.
I do know C reasonably well.
I have only a modicum of knowledge of Pascal, from my freshman years at the University.
I don't know ia-32 ASM (well, I used to, but I forgot almost everything, since I've been working with higher level languages and algorithms, mostly).
I don't know signal processing.
I want to use lossyWAV on systems that are not even related to Win32. For instance, I would love to have it working on the 11 architectures that are supported by Debian and, once the code is platform agnostic, I can package it and upload it to Debian's repository, since I will soon be a Debian Maintainer (which sould be real soon now, really).

I think that it would be a good learning excercise for both of us maintaining a version that can be compiled on many Linux distributions (and this means Ubuntu, Gentoo etc users) and also people using MacOS X.

I can start translating some of the .pas files into C (some of them seem quite trivial, while others I don't know). I would welcome help from other people so that we can get this as fast as possible released.

Well, I think that I can contribute to this project in some manner and also learn quite a bit of things and have a way to "give back".

Regards, Rogério Brito.

rbrito

Sep 16 2008, 16:55

QUOTE(rbrito @ Sep 16 2008, 19:42)

QUOTE(Nick.C @ May 12 2008, 07:05)

I think issuing lossyWAV under the GNU GPL and Copyleft will be better in the long run for the project, so that is my plan.

This was a nice and welcome choice, I think. BTW, what about putting the code in a public repository, so that you can manage the changes? If you want some help with repositories, I think that I can help. This would ease a lot the development and release of the files and also allow the project to gain momentum.
(...)

I can create a sourceforge project, if you wish. I propose it to be called lossywav, uncapitalized, since I don't know if SF handles mixed-case works well. I'm really willing to do things to get some bitrate reduction on my files.

Which version would be checked in as a working/development copy? Oh, and you can use subversion with windows perfectly, as there are clients to this. It seems that tortoisesvn is one client that is made by the people that developed Subversion.

Thanks, Rogério Brito.

Nick.C

Sep 17 2008, 01:00

Thanks for your enthusiasm and offer of transcoding skills - v1.1.0b would be the best to start from. There is already a sourceforge project created, it is just empty.

I can revert the IA-32 / x87 assembler to Delphi (though don't hold your breath - I've modified the implementation since it was Delphi, so it will be a transcode back to Delphi rather than a copy and paste). Also, you may be able to replace the nFFTdouble unit with an existing library.

If you wish to take over the management of the sourceforge project, let me know and it's yours....

rbrito

Sep 17 2008, 01:30

QUOTE(Nick.C @ Sep 17 2008, 04:00)

Thanks for your enthusiasm and offer of transcoding skills - v1.1.0b would be the best to start from. There is already a sourceforge project created, it is just empty.

Hi, Nick. I just checked the page and I think that we can cooperate on that. My id on sourceforge is just "rbrito". I'd be glad to be of help (and to accept patches from other people).

QUOTE

I can revert the IA-32 / x87 assembler to Delphi (though don't hold your breath - I've modified the implementation since it was Delphi, so it will be a transcode back to Delphi rather than a copy and paste).

Well, any way that you wish. And I hope that you don't mind me asking some pascal questions once in a while...

QUOTE

Also, you may be able to replace the nFFTdouble unit with an existing library.

It seems that we have a lot of choices regarding FFT... I just checked the repository on Debian and came up with this:

CODE

fftw-dev - library for computing Fast Fourier Transforms
fftw-docs - documentation for fftw
fftw2 - library for computing Fast Fourier Transforms
libfftw3-3 - library for computing Fast Fourier Transforms
libfftw3-dev - library for computing Fast Fourier Transforms
libfftw3-doc - documentation for fftw version 3
libgsl0ldbl - GNU Scientific Library (GSL) -- library package
mffm-fftw-dev - A C++ wrapper for the fftw.org C library (version 3)
mffm-fftw1c2 - A C++ wrapper for the fftw.org C library (version 3)
sfftw-dev - library for computing Fast Fourier Transforms
sfftw2 - library for computing Fast Fourier Transforms

QUOTE

If you wish to take over the management of the sourceforge project, let me know and it's yours....

I guess that I don't want to have the entire management, but having it shared... It can be a good learning exercise for both of us, I think.

Thank you for your very warm reply.

Rogério Brito.

QUOTE(rbrito @ Sep 17 2008, 04:25)

QUOTE

Also, you may be able to replace the nFFTdouble unit with an existing library.

It seems that we have a lot of choices regarding FFT... I just checked the repository on Debian and came up with this:
(...)

Oh, and then, there is Daniel J. Bernstein's fft programs and all his programs are in the public domain, which means that we can incorporate them into lossywav without worrying about the license.

BTW, nice that you chose GPLv3 as a license.

Regards, Rogério Brito.

2Bdecided

Sep 17 2008, 04:19

Nick,

I know little and understand less, but isn't LGPL "better" for things like codecs that people might want to link into their own software without worrying about licensing issues?

I'm recalling a recent discussion on HA with spoon (dBpoweramp) where he was taking some stick for linking GPL software.

As I say, I don't know what I'm talking about, but I thought I'd mention it anyway!

Cheers,
David.

jido

Sep 17 2008, 05:20

I don't see much point in converting to C or C++ since Pascal is portable too.

If there are Delphi-specific bits, Lazarus may provide the solution.

To my understanding, if LossyWAV remains an independant program, then GPL is appropriate. If it becomes a library it would be good to look into LGPL.

rbrito

Sep 17 2008, 13:56

QUOTE(jido @ Sep 17 2008, 08:20)

I don't see much point in converting to C or C++ since Pascal is portable too.

Perhaps you didn't notice that the source contains a good deal of ia32 assembly? This makes the program unportable.

Regards, Rogério Brito.

Nick.C

Sep 17 2008, 14:04

QUOTE(rbrito @ Sep 17 2008, 20:56)

Perhaps you didn't notice that the source contains a good deal of ia32 assembly?

I've started work on reducing the amount of assembly. I will release source of 1.1.1e when I have got further with this exercise.

Two routines converted back so far - shift_codec_blocks and fill_fft_input. Approximately a 20% speed penalty though....

[edit] This reduction process is totally reversible by means of a "USEPASONLY" compiler directive - if not defined, all converted routines revert to assembly language. [/edit]

jido

Sep 17 2008, 14:19

QUOTE(rbrito @ Sep 17 2008, 11:56)

QUOTE(jido @ Sep 17 2008, 08:20)

I don't see much point in converting to C or C++ since Pascal is portable too.

Perhaps you didn't notice that the source contains a good deal of ia32 assembly? This makes the program unportable.

Regards, Rogério Brito.

May not be portable to other architectures but certainly portable to Linux and MacOS X. Freepascal supports assembly parts.

SebastianG

Sep 18 2008, 02:32

QUOTE(jido @ Sep 17 2008, 08:20)

I don't see much point in converting to C or C++ since Pascal is portable too.

It depends on what kind of Pascal you mean and what "portable" means to you. There's an ISO standard for Pascal but it's pretty old and purely procedural (no sign of OO). But yeah, the GNU compiler collection includes a Pascal compiler that supposedly supports Borland's OO-Pascal/Delphi flavour. The programming language choice is also a political/pragmatic question. There're lots of usefull C libraries out there. Also, if you intend to go open source the number of people that can help you fix bugs / add features is of course linked to the programming language. For example: I don't like to touch/write any Pascal code. Attracting developers is more of a problem if you stick with Pascal, I suppose. Note: I'm not suggesting a conversion to C or C++. It's not my place to tell.

QUOTE(rbrito @ Sep 17 2008, 11:56)

Perhaps you didn't notice that the source contains a good deal of ia32 assembly? This makes the program unportable.

I'd think so too. It smells a bit like premature optimization, to be honest.

QUOTE(jido @ Sep 17 2008, 22:19)

May not be portable to other architectures but certainly portable to Linux and MacOS X. Freepascal supports assembly parts.

It does. But AFAIK it only supports the AT&T notation and Borland used to use Intel notation. So you'd have to rewrite your ASM parts unless there's a tool around for doing that conversion. I might be wrong, though.

Cheers,
SG

rbrito

Sep 18 2008, 18:08

QUOTE(SebastianG @ Sep 18 2008, 05:32)

QUOTE(jido @ Sep 17 2008, 08:20)

I don't see much point in converting to C or C++ since Pascal is portable too.

It depends on what kind of Pascal you mean and what "portable" means to you. There's an ISO standard for Pascal but it's pretty old and purely procedural (no sign of OO). But yeah, the GNU compiler collection includes a Pascal compiler that supposedly supports Borland's OO-Pascal/Delphi flavour. The programming language choice is also a political/pragmatic question. There're lots of usefull C libraries out there. Also, if you intend to go open source the number of people that can help you fix bugs / add features is of course linked to the programming language. For example: I don't like to touch/write any Pascal code. Attracting developers is more of a problem if you stick with Pascal, I suppose. Note: I'm not suggesting a conversion to C or C++. It's not my place to tell.

This is one important thing that you raise here.

QUOTE

QUOTE(rbrito @ Sep 17 2008, 11:56)

Perhaps you didn't notice that the source contains a good deal of ia32 assembly? This makes the program unportable.

I'd think so too. It smells a bit like premature optimization, to be honest.

Agreed 100%. And doing some optimization should be the task of the compiler. Including assembly just messes up the ability of the compiler to use registers at will, in theory, which would mean that it could generate poorer code.

QUOTE

QUOTE(jido @ Sep 17 2008, 22:19)

May not be portable to other architectures but certainly portable to Linux and MacOS X. Freepascal supports assembly parts.

It does. But AFAIK it only supports the AT&T notation and Borland used to use Intel notation. So you'd have to rewrite your ASM parts unless there's a tool around for doing that conversion. I might be wrong, though.

Not only that, but as I recall from my freshman years (please, don't ask when, it was way, way more than a decade ago

), Pascal used a stack call convention which was exactly the opposite from C. I'm sure that I will be corrected here if I'm mistaken.

Besides that, I don't see why a program like this has to be tied to ia32. For instance, I would like it to be useful on amd64, powerpc, ia32, mips, m68k etc. This program is not platform specific. It just does some computations. Nothing more, nothing less.

Regards, Rogério Brito.

rbrito

Sep 18 2008, 22:07

QUOTE(Nick.C @ Sep 17 2008, 17:04)

QUOTE(rbrito @ Sep 17 2008, 20:56)

Perhaps you didn't notice that the source contains a good deal of ia32 assembly?

I've started work on reducing the amount of assembly. I will release source of 1.1.1e when I have got further with this exercise.

Two routines converted back so far - shift_codec_blocks and fill_fft_input. Approximately a 20% speed penalty though....

[edit] This reduction process is totally reversible by means of a "USEPASONLY" compiler directive - if not defined, all converted routines revert to assembly language. [/edit]

Hi, Nick.

Well, that's actually a good thing. Can you add me as a project admin there? I can start with something that's not a moving target, then. And getting it under a version control system will ease your "Release Management" way of doing things.

Regards, Rogério Brito.

rbrito

Sep 18 2008, 22:22

QUOTE(Nick.C @ Sep 17 2008, 04:00)

If you wish to take over the management of the sourceforge project, let me know and it's yours....

Hi again, Nick.

Just if you want to see a little bit of my work on another project on SourceForge you can have a look at this log of a project. As you can see, I'm mostly the only committer, despite the fact that the project was opened a long time ago.

Regarding me being the sole admin of the ;pssywav project, I would prefer if we both collaborated as admins, as I'm not that experienced with digital sound processing as you seem to be. But porting to other architectures will also bring us some issues like arches being "big-endian" or "little-endian" (for instance).

I can deal a bit with the "Release Management" side of things and having things under SVN would help you keep the history of your modifications.

Regards, Rogério Brito.