Thread: [ReZound-users] suggestion and question
Status: Beta
Brought to you by:
ddurham
From: Alex H. <al...@sy...> - 2003-07-13 23:58:41
|
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 |
From: Davy D. <dav...@ar...> - 2003-07-14 16:46:54
|
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 |
From: Gian P. M. <the...@tu...> - 2003-07-15 01:37:32
|
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) |
From: Marc R.J. B. <mr...@dn...> - 2003-07-15 11:23:31
|
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 |
From: Davy D. <dav...@ar...> - 2003-07-15 15:41:39
|
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 |
From: Davy D. <dav...@ar...> - 2003-07-15 15:29:08
|
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. :) |