Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: lossyWAV Development (Read 559355 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

lossyWAV Development

Reply #1225
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.

lossyWAV Development

Reply #1226
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]
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV Development

Reply #1227

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.

lossyWAV Development

Reply #1228
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.

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.

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

lossyWAV Development

Reply #1229

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

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

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.

lossyWAV Development

Reply #1230
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.

lossyWAV Development

Reply #1231
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.

lossyWAV Development

Reply #1232
@Nick.C
Any news about the development of lossyWAV?

lossyWAV Development

Reply #1233
The latest development thread (1.2.0) is here.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV Development

Reply #1234
Didn't find that. Thanks Nick.

Could sombody tell me the correct code to transcode to LossyWAV with correction file?

At the moment I'm using foobar200 with following comandlines:
Code: [Select]
Encoder: c:\windows\system32\cmd.exe
Extension: lossy.tak
Parameters: /d /c C:\Programme\"Audio Tools"\foobar2000\lossyWAV.exe - --standard --silent --stdout|C:\Programme\"Audio Tools"\foobar2000\Takc.exe -e -p4 -fsl512 -ihs - %d
Format is: lossless or hybrid
Highest BPS mode supported: 24

What do I have to add to get the correction file? It should have the same file name just with the ".lwcdf.tak" extension. I know it has to do with the Command "-C" but I don't get it to work.

thanks in advance.

lossyWAV Development

Reply #1235
Here comes lossyWAV v1.1.0 for testing:

[attachment=4871:lossyWAV.zip]
lame3995o -Q1.7 --lowpass 17

lossyWAV Development

Reply #1236
Could sombody tell me the correct code to transcode to LossyWAV with correction file?

At the moment I'm using foobar200 with following comandlines:


Sorry for the lateness of my reply.

I think correction files are incompatible with piping the output of lossyWAV direct to the standard input of an encoder (such as TAK). That's because there are now two output files from lossyWAV and there's no way on the command line to create two instances of TAK to accept two streams of standard input from lossyWAV's two outputs.

The way to do it would be using commandline or batch files and I think you'll need an uncompressed PCM WAV file as input to lossyWAV to generate wav and correction files which you can then compress using takc when complete. You may wish to copy tags across as well using another commandline tool or by means of a separate CUE sheet.

Personally, correction files aren't of great interest to me so I have no specific suggestions.
Dynamic – the artist formerly known as DickD

lossyWAV Development

Reply #1237
You may wish to copy tags across as well using another commandline tool or by means of a separate CUE sheet.

Personally, correction files aren't of great interest to me so I have no specific suggestions.


According to the Wiki, CUEtools can compress any lossless file using lossyWAV + correction file.
Dynamic – the artist formerly known as DickD

lossyWAV Development

Reply #1238
.... and I think you'll need an uncompressed PCM WAV file as input to lossyWAV to generate wav and correction files which you can then compress....
You can pipe FLAC decompressed output into lossyWAV and create processed and correction output files (just not with --stdout!).
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)