Re: [ReZound-users] suggestion and question

On Mon, 14 Jul 2003, Gian Paolo Mureddu wrote:
> Davy Durham wrote:
[32 bit floating point vs. 16 bit integer]
> >After LADSPA I'm thinking this is the next thing to address.
> Hey, why not having the option to make a recording in either one, 32-bit
> float or 16-bit integer? That might take longer to compile or even a
> larger program, but I thought that could be great! (I am not a coder, so
> I wouldn't know of any problems at code level)
Once code works with float32 internally, there is not much of a point in
keeping integer code. I understand that currently the main issue is
worries about performance, mainly due to increased disk I/O. Why not
optionally do the on-disk processing at float24 rather than float32?
This would give only half the disk IO performance loss compared to
float32, while already giving much better fidelity
than the 16 bit stored in file (e.g. is virtually lossless).
If a file was originally stored in 24 bit or better, it is always
possible to use 32 bit work files for those. Of course all math can
still be carried out in 32bit float even when using only a 24bit
float work file.
I'm not familiar yet with the native file format of rezound, but an audio
program with its own native format could do completely lossless editing
by simply storing the original files plus the edit operations they were
subjected to. (a bit similar to the format photoshop uses for saving
images). When saving to wav, mp3 or any other format, this data could
be processed to output the correct sample values.
grtz
MRJB

Thread view

Hi Davy,
ReZound's great. I have a (potentially helpful to someone other than me)
suggestion. The actions you have hotkeys for (ctrl-x for cut, etc) that you
also can shift-click on the menu item to bring up an expanded menu; if there
was a shift-hotkey that would bring up the expanded menu (shift-ctrl-x), it
could make the hotkeys more powerful.
I also have a question: If I bring in a sound and lower the volume doing
"Change Volume" from the "Effects" menu, then save it, is it altering the
sound aside from lowering the amplitude of the playback for that channel? For
example, if I bring in a loud sound (near 0dB) and lower it this way to
barely audible, if a month later I decide I want that channel back at 0 dB,
will it still have the same fidelity as the original signal? I know if I
record a sound on an old tape deck and mix it to another tape at a lower
volume, I will lose a lot of fidelity in the new version. But if I am only
trimming the volume as the original sound goes through a mixer, the original
track still retains it's sonic quality. How does the "Change Volume" work,
like a mixer, which retains the track's fidelity, or does it actually reduce
the signal when it saves it to the disk?
Thanks,
Alex

On Sun, 2003-07-13 at 13:59, Alex Heizer wrote:
> Hi Davy,
>
> ReZound's great. I have a (potentially helpful to someone other than me)
> suggestion. The actions you have hotkeys for (ctrl-x for cut, etc) that you
> also can shift-click on the menu item to bring up an expanded menu; if there
> was a shift-hotkey that would bring up the expanded menu (shift-ctrl-x), it
> could make the hotkeys more powerful.
Hmm.. I'll have to see if that's possible with FOX. Basically FOX lets
you assign a single key combination to a menu item. So one containing
'shift' would be a different one from one NOT containing 'shift' in the
key combination. But I'll see if there's a work around. I think I had
in mind to do this before but ran into this being the problem. I didn't
pursue it because I didn't know just how much users would be using the
keyboard instead of the mouse.
>
> I also have a question: If I bring in a sound and lower the volume doing
> "Change Volume" from the "Effects" menu, then save it, is it altering the
> sound aside from lowering the amplitude of the playback for that channel? For
> example, if I bring in a loud sound (near 0dB) and lower it this way to
> barely audible, if a month later I decide I want that channel back at 0 dB,
> will it still have the same fidelity as the original signal? I know if I
> record a sound on an old tape deck and mix it to another tape at a lower
> volume, I will lose a lot of fidelity in the new version. But if I am only
> trimming the volume as the original sound goes through a mixer, the original
> track still retains it's sonic quality. How does the "Change Volume" work,
> like a mixer, which retains the track's fidelity, or does it actually reduce
> the signal when it saves it to the disk?
Yep, welcome to the world of integers [well, you've actually been here
all along]. Yes, currently, if you lower the volume by a factor of say
10 then raise it by a factor of 10.. then, for example, a sample value
of 2345 (when divided by 10 becomes 234.5 but the .5 is chopped of in
integer land) becomes 2340 and you've lost some precision(fidelity).
(Of course if you lower it by 10, then 'undo', you get the original back
because it's restoring from a copy of the original.)
This is however MUCH less of an issue with floating point formats. It
would only be a problem when cutting the volume by enormous amounts
(which really just doesn't happen with usual recording situations).
The disadvantage (as has been discussed a few days ago on this list) is
the size of the data file is doubled now that you're using 32bit floats
instead of 16bit integers. And the processing time takes a little
longer because floating point math takes longer on some processors and
there's simple twice as much data to pipe around through the system now.
The advantages outweigh the disadvantages for really any serious
audiophile however, so I'm planning to give the user their choice of
either mode (requiring a recompile, or simply two separate compiles).
After LADSPA I'm thinking this is the next thing to address.
-- Davy

Davy Durham wrote:
>The advantages outweigh the disadvantages for really any serious
>audiophile however, so I'm planning to give the user their choice of
>either mode (requiring a recompile, or simply two separate compiles).
>After LADSPA I'm thinking this is the next thing to address.
>
>
Hey, why not having the option to make a recording in either one, 32-bit
float or 16-bit integer? That might take longer to compile or even a
larger program, but I thought that could be great! (I am not a coder, so
I wouldn't know of any problems at code level)

On Mon, 14 Jul 2003, Gian Paolo Mureddu wrote:
> Davy Durham wrote:
[32 bit floating point vs. 16 bit integer]
> >After LADSPA I'm thinking this is the next thing to address.
> Hey, why not having the option to make a recording in either one, 32-bit
> float or 16-bit integer? That might take longer to compile or even a
> larger program, but I thought that could be great! (I am not a coder, so
> I wouldn't know of any problems at code level)
Once code works with float32 internally, there is not much of a point in
keeping integer code. I understand that currently the main issue is
worries about performance, mainly due to increased disk I/O. Why not
optionally do the on-disk processing at float24 rather than float32?
This would give only half the disk IO performance loss compared to
float32, while already giving much better fidelity
than the 16 bit stored in file (e.g. is virtually lossless).
If a file was originally stored in 24 bit or better, it is always
possible to use 32 bit work files for those. Of course all math can
still be carried out in 32bit float even when using only a 24bit
float work file.
I'm not familiar yet with the native file format of rezound, but an audio
program with its own native format could do completely lossless editing
by simply storing the original files plus the edit operations they were
subjected to. (a bit similar to the format photoshop uses for saving
images). When saving to wav, mp3 or any other format, this data could
be processed to output the correct sample values.
grtz
MRJB

On Tue, 2003-07-15 at 06:20, Marc R.J. Brevoort wrote:
> Once code works with float32 internally, there is not much of a point in
> keeping integer code.
(actually I'm hoping there to be not difference in the code, baically
only that the data type is float instead of int16_t and MIN_SAMPLE is
#defined -1.0 instead of -32767 and MAX_SAMPLE is #defined 1.0 instead
of 32767.. so the code should be the same.. again this is what I'm
hoping, yet I'll have to see if this can actually happen)
> I understand that currently the main issue is
> worries about performance, mainly due to increased disk I/O. Why not
> optionally do the on-disk processing at float24 rather than float32?
> This would give only half the disk IO performance loss compared to
> float32, while already giving much better fidelity
> than the 16 bit stored in file (e.g. is virtually lossless).
>
there is no float24 type as far as I know. 'float' in the ANSI C
standard is require to conform to the IEEE 32bit floating point standard
(the IEEE #1234 slips my mind at the moment). And 'double' is to be
IEEE 64bit floating point standard. (I think 'long double' 80bit is an
extension that most modern compilers support)
That's all you get in ANSI C99 :-/
But besides that, even if there were a float24 type, the CPU is going to
do 32bit float point operations, so it would have to be
padded-out/converted (not a free operation) to a 32bit float in the
register, then do the operation, then convert back to 24bit.. . All
that not being free.. It might be better just to store 32bits on disk
in the temp file too.
:wq Davy

On Mon, 2003-07-14 at 15:39, Gian Paolo Mureddu wrote:
> Hey, why not having the option to make a recording in either one, 32-bit
> float or 16-bit integer? That might take longer to compile or even a
> larger program, but I thought that could be great! (I am not a coder, so
> I wouldn't know of any problems at code level)
Yeah, that might be a possibility. But remember, the format you choose
to save a file in is independent of the format I choose to make be the
internal format for the temporary working file.
So, if the internal format is floats, then you can lower and raise the
amplitude during the same editing session and no loss in quality.
Now, if you save the file between the lowering and raising:
if you save it in floating point it's no problem
if you save it in integer format you have loss after you load it again
and raise it.
Eh, but maybe this doesn't have so much to do with your wanting a choice
at record time. :)