audio capabilities
tho...@antispam.ham
capabilities? I'm thinking of something analogous to the ways
one can query a system with regard to its video capabilities,
such as horizontal and vertical resolution and bit depth. Is
there anything like that for audio capabilities?
Presumably a system can do no better than its weakest link,
and in the case of an OS/2 computer, one would think that the
links include the capabilities of the sound card hardware, the
capabilities of the sound card driver, the capabilities of the
operating system, and lastly the capabilities of the application
software. For example, I can write my audio editing application
software to handle 24-bit/96 kHz .WAV files, but I can't play
them unless the sound card, the driver for it, and the operating
system all support it. Does anyone know what OS/2 itself
supports regarding bit depth and sampling rate? How about the
UNIAUD driver?
Ilya Zakharevich
> Are there ways to query a system with regard to its audio
> capabilities? I'm thinking of something analogous to the ways
> one can query a system with regard to its video capabilities,
> such as horizontal and vertical resolution and bit depth. Is
> there anything like that for audio capabilities?
>
> Presumably a system can do no better than its weakest link,
> and in the case of an OS/2 computer, one would think that the
> links include the capabilities of the sound card hardware, the
> capabilities of the sound card driver, the capabilities of the
> operating system, and lastly the capabilities of the application
> software. For example, I can write my audio editing application
> software to handle 24-bit/96 kHz .WAV files, but I can't play
> them unless the sound card, the driver for it, and the operating
> system all support it.
Why do you think so? (Remember the audio driver for a PC's beeper?)
Yours,
Ilya
tho...@antispam.ham
>> Are there ways to query a system with regard to its audio
>> capabilities? I'm thinking of something analogous to the ways
>> one can query a system with regard to its video capabilities,
>> such as horizontal and vertical resolution and bit depth. Is
>> there anything like that for audio capabilities?
>>
>> Presumably a system can do no better than its weakest link,
>> and in the case of an OS/2 computer, one would think that the
>> links include the capabilities of the sound card hardware, the
>> capabilities of the sound card driver, the capabilities of the
>> operating system, and lastly the capabilities of the application
>> software. For example, I can write my audio editing application
>> software to handle 24-bit/96 kHz .WAV files, but I can't play
>> them unless the sound card, the driver for it, and the operating
>> system all support it.
>
> Why do you think so?
For one thing, it makes sense.
But in this case, actual experience shows that OS/2 won't
play a 24-bit 96 kHz recording.
> (Remember the audio driver for a PC's beeper?)
That's not the same thing as music.
Marty
Rendering it, and actually playing it in its original quality are two
different things, of course. ;-)
But I don't think MMOS/2 is equipped to handle anything > 16 bits per
sample per "voice" (left/right for stereo, or some drivers even
supported 4 "voices"). The data would have to be converted, with the
appropriate loss of precision.
It might be possible to bypass MMOS/2 with a direct ALSA/UniAud
interface, but I don't really have a clue about that.
--
[Reverse the parts of the e-mail address to reply.]
Ilya Zakharevich
>>> and in the case of an OS/2 computer, one would think that the
>>> links include the capabilities of the sound card hardware, the
>>> capabilities of the sound card driver, the capabilities of the
>>> operating system, and lastly the capabilities of the application
>>> software. For example, I can write my audio editing application
>>> software to handle 24-bit/96 kHz .WAV files, but I can't play
>>> them unless the sound card, the driver for it, and the operating
>>> system all support it.
>>
>> Why do you think so?
> For one thing, it makes sense.
AFAICS, absolutely no sense. You do not care about the weakest link;
you think about the strongest link.
E.g., given no restriction on CPU usage, you find the "strongest"
format supported by the system, and convert your data to it (I assume
that there is no "exact match" format). Then the system would do its
magic to present it to the listener in the best possible way.
If CPU usage is a critical issue (probably would never happen nowadays),
you use the "worst" of formats which are "better" than your data.
> But in this case, actual experience shows that OS/2 won't
> play a 24-bit 96 kHz recording.
No, it is YOUR APPLICATION which won't play it. I can play any format
I have a reader for...
Anyway, this example is extremely silly: there is no purpose [*] in
playback (or deployment) of anything above about 15bit/44kHz
("theoretical arguments" show that with noise shaping about 13bit
might be enough, but I never saw experimental data involving noise
shaping).
[*] Well, of course it has a lot of purpose - if what you want is to
increase the revenue of the distributor... Force people to buy
yet another copy of the same contents - and make it harder to
"backup" it.
Having the better formats IS crucial for RECORDING and
PROCESSING, of course - just not for playback...
>> (Remember the audio driver for a PC's beeper?)
> That's not the same thing as music.
??? It is a way to deliver 8-bit (?) contents via 1-bit hardware -
which shows that your arguments are fundamentally wrong.
Yours,
Ilya
tho...@antispam.ham
>>>> Presumably a system can do no better than its weakest link,
>>>> and in the case of an OS/2 computer, one would think that the
>>>> links include the capabilities of the sound card hardware, the
>>>> capabilities of the sound card driver, the capabilities of the
>>>> operating system, and lastly the capabilities of the application
>>>> software. For example, I can write my audio editing application
>>>> software to handle 24-bit/96 kHz .WAV files, but I can't play
>>>> them unless the sound card, the driver for it, and the operating
>>>> system all support it.
>>> Why do you think so?
>> For one thing, it makes sense.
> AFAICS, absolutely no sense. You do not care about the weakest link;
> you think about the strongest link.
Nonsense; I can and have written code that can deal with 24-bit
96 kHz .WAV files. That's the strongest link. Doesn't do me
any good, because the rest of the system doesn't support the
playing of 24-bit 96 kHz .WAV files, but I don't know whether
it's the hardware (sound card), the driver for it, or the
operating system that is the limiting factor, namely the weak
link. Nor do I know what the limits of the system are. That's
why I'm looking for a way to query the capabilities of a system.
> E.g., given no restriction on CPU usage, you find the "strongest"
> format supported by the system, and convert your data to it (I assume
> that there is no "exact match" format). Then the system would do its
> magic to present it to the listener in the best possible way.
In other words, you find the weakest link. That's not supporting
your argument at all.
> If CPU usage is a critical issue (probably would never happen nowadays),
> you use the "worst" of formats which are "better" than your data.
But what is the "worst" of the supported formats? That brings us
back to my original question, namely if there is a way to query
the capabilities of the audio subsystem, and you've done nothing
to address that question.
>> But in this case, actual experience shows that OS/2 won't
>> play a 24-bit 96 kHz recording.
> No, it is YOUR APPLICATION which won't play it.
Both mine and another application, which reported a hardware error.
Although I suspect the "hardware error" is an unsupported bit depth
and sampling rate, I can't be positive because the error message
wasn't detailed enough. Hence the desire to query the system as
to its capabilities.
> I can play any format I have a reader for...
I doubt it. The "reader" would need to convert to a different
format that is supported.
> Anyway, this example is extremely silly: there is no purpose [*] in
> playback (or deployment) of anything above about 15bit/44kHz
I disagree.
> ("theoretical arguments" show that with noise shaping about 13bit
> might be enough, but I never saw experimental data involving noise
> shaping).
Irrelevant in this case, because I know the system can support
16-bit 44.1 kHz .WAV files, that is, the audio CD standard. I'd
like to know whether the system can go beyond that. There are
vendors out there who sell high resolution sound cards. Obviously
the capabilities of the audio card differ from card to card. How
can I query the system to find out the capabilities of whatever
card is installed?
> [*] Well, of course it has a lot of purpose - if what you want is to
> increase the revenue of the distributor... Force people to buy
> yet another copy of the same contents - and make it harder to
> "backup" it.
My interest has nothing to do with the revenue of the distributor.
> Having the better formats IS crucial for RECORDING and
> PROCESSING, of course - just not for playback...
I already have the recordings. My processing software software can
handle the higher resolution formats. I want to hear the results
without having to do a sampling rate conversion and bit reduction
every time in software, because the quality of a sampling rate
conversion depends on how far you extend the sync interpolator,
which means the more CPU time you spend on it, the better the
results. I don't want to put up with time lags while the CPU is
doing the conversion.
>>> (Remember the audio driver for a PC's beeper?)
>> That's not the same thing as music.
> ??? It is a way to deliver 8-bit (?) contents via 1-bit hardware -
Well, you just go ahead and try to listen to a 24-bit 96 kHz
recording with your 1-bit hardware and evaluate the result of
some edit you made.
> which shows that your arguments are fundamentally wrong.
I asked a question, namely how to query the audio capabilities of
a system. That's not an argument. As for fundamentally wrong
arguments, try your logic on the video. Try displaying a
1920x1200 32-bit-depth image on a 640x480 8-bit-depth display.
Oh, I'm sure you can down-convert it to fit, but if the goal is
to evaluate an edit that the down conversion destroys in the
process, you're out of luck. That is, your arguments are
fundamentally wrong.
Ilya Zakharevich
>> you think about the strongest link.
> Nonsense; I can and have written code that can deal with 24-bit
> 96 kHz .WAV files. That's the strongest link. Doesn't do me
> any good, because the rest of the system doesn't support the
> playing of 24-bit 96 kHz .WAV files, but I don't know whether
> it's the hardware (sound card), the driver for it, or the
> operating system that is the limiting factor, namely the weak
> link.
If you do not know, let me tell you: the fault is in your application.
> Nor do I know what the limits of the system are. That's
> why I'm looking for a way to query the capabilities of a system.
Now *this* makes sense. You are interested in what the API you are
using accepts, not in what the weakiest link accepts.
>> E.g., given no restriction on CPU usage, you find the "strongest"
>> format supported by the system, and convert your data to it (I assume
>> that there is no "exact match" format). Then the system would do its
>> magic to present it to the listener in the best possible way.
> In other words, you find the weakest link.
No.
> But what is the "worst" of the supported formats? That brings us
> back to my original question, namely if there is a way to query
> the capabilities of the audio subsystem, and you've done nothing
> to address that question.
What I addressed are your misconceptions about what the question is.
>> I can play any format I have a reader for...
> I doubt it. The "reader" would need to convert to a different
> format that is supported.
Sure. Why would I need it if it does nothing? ;-)
> I already have the recordings. My processing software software can
> handle the higher resolution formats. I want to hear the results
> without having to do a sampling rate conversion and bit reduction
> every time in software, because the quality of a sampling rate
> conversion depends on how far you extend the sync interpolator,
> which means the more CPU time you spend on it, the better the
> results.
There is 0 gain in going above 16bit/44kHz, and the finer details of
the down-conversion have no relevance.
> I don't want to put up with time lags while the CPU is
> doing the conversion.
CPU is doing the conversion (at least copying from one memory location
to another) anyway. So I see no difference in having 1ms delay vs
0.1ms delay - in my experience with video, desync below 10ms is not
noticable.
>>>> (Remember the audio driver for a PC's beeper?)
>
>>> That's not the same thing as music.
>
>> ??? It is a way to deliver 8-bit (?) contents via 1-bit hardware -
>
> Well, you just go ahead and try to listen to a 24-bit 96 kHz
> recording with your 1-bit hardware and evaluate the result of
> some edit you made.
Irrelevant.
>> which shows that your arguments are fundamentally wrong.
>
> I asked a question, namely how to query the audio capabilities of
> a system. That's not an argument. As for fundamentally wrong
> arguments, try your logic on the video. Try displaying a
> 1920x1200 32-bit-depth image on a 640x480 8-bit-depth display.
> Oh, I'm sure you can down-convert it to fit, but if the goal is
> to evaluate an edit that the down conversion destroys in the
> process, you're out of luck. That is, your arguments are
> fundamentally wrong.
BS. If your screen is 25", and you view it from 20' distance, the
down-conversion won't matter. From 50' distance, even 256colors
display would give you results undistinguisable from 48-bit displays
(with proper dithering). Likewise for audio - downconversion produces
no audible effect as far as the target format is CD-or-better.
Hope this helps,
Ilya
tho...@antispam.ham
>>> AFAICS, absolutely no sense. You do not care about the weakest link;
>>> you think about the strongest link.
>> Nonsense; I can and have written code that can deal with 24-bit
>> 96 kHz .WAV files. That's the strongest link. Doesn't do me
>> any good, because the rest of the system doesn't support the
>> playing of 24-bit 96 kHz .WAV files, but I don't know whether
>> it's the hardware (sound card), the driver for it, or the
>> operating system that is the limiting factor, namely the weak
>> link.
> If you do not know, let me tell you: the fault is in your application.
Hardly, given that another application (not mine) also fails to
play a 24-bit 96 kHz .WAV file. Of course, I said that already.
>> Nor do I know what the limits of the system are. That's
>> why I'm looking for a way to query the capabilities of a system.
> Now *this* makes sense.
It's the original question I asked. So far, you haven't even
attempted to answer it.
> You are interested in what the API you are
> using accepts, not in what the weakiest link accepts.
On the contrary, I am interested in what the weakest link accepts,
because it will do no good to write an application that the API
accepts, but the hardware does not.
>>> E.g., given no restriction on CPU usage, you find the "strongest"
>>> format supported by the system, and convert your data to it (I assume
>>> that there is no "exact match" format). Then the system would do its
>>> magic to present it to the listener in the best possible way.
>> In other words, you find the weakest link.
> No.
Maybe you just don't understand simple English. The reason why
you can't display a full 4000 by 3000 pixel image with 32-bit detph
from a digital camera on a system that only supports VGA is because
VGA is the weakest link.
>> But what is the "worst" of the supported formats? That brings us
>> back to my original question, namely if there is a way to query
>> the capabilities of the audio subsystem, and you've done nothing
>> to address that question.
> What I addressed are your misconceptions about what the question is.
Nonsense, given that I don't have any misconception about what the
question is.
>>> I can play any format I have a reader for...
>> I doubt it. The "reader" would need to convert to a different
>> format that is supported.
> Sure.
Then by definition it isn't playing the format. It's like taking
the 4000 by 3000 pixel image and picking every sixth pixel in each
direction (or averaging them) to fit the image into a VGA display.
Just because you have a program that can do that conversion doesn't
mean it's showing the image the way it was intended to.
> Why would I need it if it does nothing? ;-)
Getting the samples from a .WAV file to a sound card isn't exactly
my idea of doing nothing.
>> I already have the recordings. My processing software software can
>> handle the higher resolution formats. I want to hear the results
>> without having to do a sampling rate conversion and bit reduction
>> every time in software, because the quality of a sampling rate
>> conversion depends on how far you extend the sync interpolator,
>> which means the more CPU time you spend on it, the better the
>> results.
> There is 0 gain in going above 16bit/44kHz,
Once again, I disagree.
> and the finer details of the down-conversion have no relevance.
Nonsense. Have you ever used audio editing software like Audacity,
for example? It has a choice of sampling rate conversion methods,
one being fast and the other being good. Obviously the author of
that software finds some relevance to the down-conversion method.
>> I don't want to put up with time lags while the CPU is
>> doing the conversion.
> CPU is doing the conversion (at least copying from one memory location
> to another) anyway.
Sampling rate conversion is more than just copying from one memory
location to another. Simple factors of 2 could be handled that way,
however.
> So I see no difference in having 1ms delay vs
> 0.1ms delay - in my experience with video, desync below 10ms is not
> noticable.
And how do know that the delay caused by doing "good" sampling rate
conversion is only 1 ms? Why does Audacity offer the "fast" option
if "good" is fast enough?
>>>>> (Remember the audio driver for a PC's beeper?)
>>>> That's not the same thing as music.
>>> ??? It is a way to deliver 8-bit (?) contents via 1-bit hardware -
>> Well, you just go ahead and try to listen to a 24-bit 96 kHz
>> recording with your 1-bit hardware and evaluate the result of
>> some edit you made.
> Irrelevant.
Nonsense again. The example invalidates your argument.
>>> which shows that your arguments are fundamentally wrong.
>> I asked a question, namely how to query the audio capabilities of
>> a system. That's not an argument. As for fundamentally wrong
>> arguments, try your logic on the video. Try displaying a
>> 1920x1200 32-bit-depth image on a 640x480 8-bit-depth display.
>> Oh, I'm sure you can down-convert it to fit, but if the goal is
>> to evaluate an edit that the down conversion destroys in the
>> process, you're out of luck. That is, your arguments are
>> fundamentally wrong.
> BS.
Call your arguments fundamentally wrong or call them BS. It means
the same to me.
> If your screen is 25", and you view it from 20' distance, the
> down-conversion won't matter.
The key word here is "If". When I'm editing audio, it's not
background music for me.
> From 50' distance, even 256colors
> display would give you results undistinguisable from 48-bit displays
> (with proper dithering). Likewise for audio - downconversion produces
> no audible effect as far as the target format is CD-or-better.
And you really think that everybody agrees with you on that?
> Hope this helps,
Not in the slightest. My question stands: is there a way to query the
audio capabilities of a system?
James J. Weinkam
> Nonsense; I can and have written code that can deal with 24-bit
> 96 kHz .WAV files. That's the strongest link. Doesn't do me
> any good, because the rest of the system doesn't support the
> playing of 24-bit 96 kHz .WAV files, but I don't know whether
> it's the hardware (sound card), the driver for it, or the
> operating system that is the limiting factor, namely the weak
> link. Nor do I know what the limits of the system are. That's
> why I'm looking for a way to query the capabilities of a system.
>
drivers will play 16 bit, 44100 stereo wav files as well as a variety of lower
sampling rates and sample sizes with suitable software, but at present they do
not support playback at higher sampling rates or sizes or recording.
The windows software and drivers that came with the card fully support all its
features for recording and playback; however attempts to edit or convert from
24 to 16 bits either crash the system or result in corrupt wav files for
recordings of any size.
I record live performances of the Senior Vancouver Youth Symphony Orchestra in
theaters such as the Michael J. Fox theater or the Kay Meek Center at 24-44100
using a stereo point microphone. I convert to 16-44100 wav files in eCS using
editing software I wrote myself. The resulting cd's are indistinguishable from
commercial cd's.
So the answer to your question is that it is probably the drivers. The
difficulty is writing software to operate the card is that the the ICOTL
interface is inaccurately and incompletely documented. The command line mixer
application that comes with uniaud is buggy and is only able to set some of
the controls. I don't recall the exact details, since it has been a couple of
years since I messed with it,
Carsten Arnold's playrec works for playback but not for recording.
Unfortunately he is no longer maintaining the program.
Marty
> tho...@antispam.ham wrote:
>> Nonsense; I can and have written code that can deal with 24-bit
>> 96 kHz .WAV files. That's the strongest link. Doesn't do me
>> any good, because the rest of the system doesn't support the
>> playing of 24-bit 96 kHz .WAV files, but I don't know whether
>> it's the hardware (sound card), the driver for it, or the
>> operating system that is the limiting factor, namely the weak
>> link. Nor do I know what the limits of the system are. That's
>> why I'm looking for a way to query the capabilities of a system.
>>
> I have a Creative Labs Soundblaster Audigy 4 24 bit sound card. The
> uniaud drivers will play 16 bit, 44100 stereo wav files as well as a
> variety of lower sampling rates and sample sizes with suitable software,
> but at present they do not support playback at higher sampling rates or
> sizes or recording.
>
> The windows software and drivers that came with the card fully support
> all its features for recording and playback; however attempts to edit or
> convert from 24 to 16 bits either crash the system or result in corrupt
> wav files for recordings of any size.
>
> I record live performances of the Senior Vancouver Youth Symphony
> Orchestra in theaters such as the Michael J. Fox theater or the Kay Meek
> Center at 24-44100 using a stereo point microphone. I convert to
> 16-44100 wav files in eCS using editing software I wrote myself. The
> resulting cd's are indistinguishable from commercial cd's.
I'm sure it is, however this may not be the case when the source is
24-bit. As (I think) David was alluding to, there are certain harmonics
that get introduced whenever you change the resolution (frequency and/or
amplitude) of a waveform. If your original recording is 16 bit stereo,
you are not subject to the errors introduced by the reduced resolution.
A sample that was originally 24 bits however, could become a less
"perfect" 16 bit sample than it would have been if it was recorded at 16
bit resolution from the beginning.
--
[Reverse the parts of the e-mail address to reply.]
James J. Weinkam
> I'm sure it is, however this may not be the case when the source is
> 24-bit. As (I think) David was alluding to, there are certain harmonics
> that get introduced whenever you change the resolution (frequency and/or
> amplitude) of a waveform. If your original recording is 16 bit stereo,
> you are not subject to the errors introduced by the reduced resolution.
> A sample that was originally 24 bits however, could become a less
> "perfect" 16 bit sample than it would have been if it was recorded at 16
> bit resolution from the beginning.
>
computation required is complicated and time consuming. That is why I record
at 44100. Rescaling to convert from 24 to 16 bits is a linear transformation
(up to discretization error, which is miniscule) and introduces no distortion.
It is equivalent to turning the volume down.
Ilya Zakharevich
>> You are interested in what the API you are
>> using accepts, not in what the weakiest link accepts.
>
> On the contrary, I am interested in what the weakest link accepts,
> because it will do no good to write an application that the API
> accepts, but the hardware does not.
If the API accepts it, you do not care about "any other link" of the
system. It is the task of the API implementation to handle the data
so the user can hear it.
> Maybe you just don't understand simple English. The reason why
> you can't display a full 4000 by 3000 pixel image with 32-bit detph
> from a digital camera on a system that only supports VGA is because
> VGA is the weakest link.
Complete BS: I CAN show this image on VGA.
> Nonsense, given that I don't have any misconception about what the
> question is.
LOL!
> Then by definition it isn't playing the format. It's like taking
> the 4000 by 3000 pixel image and picking every sixth pixel in each
> direction (or averaging them) to fit the image into a VGA display.
> Just because you have a program that can do that conversion doesn't
> mean it's showing the image the way it was intended to.
Frankly speaking, when I view images, I do not care much about the
intent of the original creator. My agenda is more important to me
than theirs.
> Nonsense. Have you ever used audio editing software like Audacity,
> for example? It has a choice of sampling rate conversion methods,
> one being fast and the other being good. Obviously the author of
> that software finds some relevance to the down-conversion method.
Who cares? Some people claim that the quality of HDMI cable matters;
some claim that quality of the speaker cable matters; some people even
think that $20000 stereo produces better sound than $200 stereo.
They are proven wrong again and again by double-blind testing - but
why should they care? They know better...
>>> I don't want to put up with time lags while the CPU is
>>> doing the conversion.
>
>> CPU is doing the conversion (at least copying from one memory location
>> to another) anyway.
>
> Sampling rate conversion is more than just copying from one memory
> location to another.
Sure. So you are measuring one type of conversion vs another one, not
conversion vs no-conversion.
>> If your screen is 25", and you view it from 20' distance, the
>> down-conversion won't matter.
>
> The key word here is "If". When I'm editing audio, it's not
> background music for me.
No matter how good your intentions are, human ear is not able to here
some things.
>> Likewise for audio - downconversion produces
>> no audible effect as far as the target format is CD-or-better.
> And you really think that everybody agrees with you on that?
And do you really think that "everybody agreeing with me" is a
meaningful metric? A double-blind test from a trustworthy source
with no meaningful critique following it is enough.
Hope this helps,
Ilya
Ilya Zakharevich
>> I'm sure it is, however this may not be the case when the source is
>> 24-bit. As (I think) David was alluding to, there are certain harmonics
>> that get introduced whenever you change the resolution (frequency and/or
>> amplitude) of a waveform. If your original recording is 16 bit stereo,
>> you are not subject to the errors introduced by the reduced resolution.
>> A sample that was originally 24 bits however, could become a less
>> "perfect" 16 bit sample than it would have been if it was recorded at 16
>> bit resolution from the beginning.
This is applicable only if one uses "naive rounding" as the way to
chip off extra bits.
> Changing sampling rate without introducing distortion is possible but the
> computation required is complicated and time consuming.
The computational requirement is addition of two 24-bit quantities.
So it is neither complicated nor time consuming.
[You generate 1-sec sample of sawtooth-distributed noise twice (for
L/R), and rescale it so that it becomes distributed between levels
-0.5 and +1.5 of the lower-resolution format (so between -128 and
384 when you remove 8bits). Store it in memory; then for every
1-sec chunk of the recording, add it to your 24-bit streams, then
truncate 8 bits.
If you want to be fancy, do noise shaping over this sample. But I
doubt it would matter any - double-blind experiments show that the
method above gives a stream which is undistinguishable (in A/B/X
sense) from the full 24-bit stream.]
Yours,
Ilya
James J. Weinkam
converting from 96 (or 48)KHz and 44.1KHz sample rate. The latter is more
complicated than the former.
tho...@antispam.ham
>>> You are interested in what the API you are
>>> using accepts, not in what the weakiest link accepts.
>> On the contrary, I am interested in what the weakest link accepts,
>> because it will do no good to write an application that the API
>> accepts, but the hardware does not.
> If the API accepts it, you do not care about "any other link" of the
> system.
Nonsense. Just because an API supports long filenames, for example,
doesn't mean that you can write a long filename to a FAT16 floppy
disk. The floppy disk's file system is the weakest link in this
case.
> It is the task of the API implementation to handle the data
> so the user can hear it.
Then the API would need to make assumptions about what the
hardware can handle.
>> Maybe you just don't understand simple English. The reason why
>> you can't display a full 4000 by 3000 pixel image with 32-bit detph
>> from a digital camera on a system that only supports VGA is because
>> VGA is the weakest link.
> Complete BS: I CAN show this image on VGA.
I'm aware that your statement is complete BS, given that VGA offers
only 640x480 resolution, which means it's physical impossible to
display a full 4000x3000 pixel image.
>> Nonsense, given that I don't have any misconception about what the
>> question is.
> LOL!
Laugh all you want. Your position keeps getting more and more
bizarre.
>> Then by definition it isn't playing the format. It's like taking
>> the 4000 by 3000 pixel image and picking every sixth pixel in each
>> direction (or averaging them) to fit the image into a VGA display.
>> Just because you have a program that can do that conversion doesn't
>> mean it's showing the image the way it was intended to.
> Frankly speaking, when I view images, I do not care much about the
> intent of the original creator.
What if the original creator happens to be yourself? Are you saying
that you don't care about your own intent?
> My agenda is more important to me than theirs.
Then you should at least care about your own intent.
>> Nonsense. Have you ever used audio editing software like Audacity,
>> for example? It has a choice of sampling rate conversion methods,
>> one being fast and the other being good. Obviously the author of
>> that software finds some relevance to the down-conversion method.
> Who cares?
Those who use it. You obviously don't.
> Some people claim that the quality of HDMI cable matters;
> some claim that quality of the speaker cable matters; some people even
> think that $20000 stereo produces better sound than $200 stereo.
And some people are right, and some people are wrong.
> They are proven wrong again and again by double-blind testing - but
> why should they care?
Some are proven wrong, and some are proven right. The quality of
microphone cable matters. Phantom powered microphones can reveal
problems with cables that non-phantom powered microphones do not.
I learned that myself the hard way, when a microphone cable that
had served me just fine with self-powered microphones produced a
crackling sound with phantom powered microphones whenver the cable
was handled. I'm well aware that overkill is possible, and some
companies have made lots of money selling overpriced products that
don't work any better, but they managed to convince the consumer
that they do work better. Now, if you want to spend a lot of time
trying to convince me that I don't need 24-bit 96 kHz audio, that's
your business, but it doesn't answer the question that I originally
asked. The question stands, regardless of your own personal opinion.
> They know better...
Well, my agenda is more important to me than your agenda, so why
don't you just answer the question, if you know the answer, or
just leave the thread? I've learned absolutely nothing from you,
though I've learned plenty ABOUT you, none of it favorable.
>>>> I don't want to put up with time lags while the CPU is
>>>> doing the conversion.
>>> CPU is doing the conversion (at least copying from one memory location
>>> to another) anyway.
>> Sampling rate conversion is more than just copying from one memory
>> location to another.
> Sure. So you are measuring one type of conversion vs another one, not
> conversion vs no-conversion.
One consumes considerably more CPU time than the other. I don't
want to put up with the CPU intensive method.
>>> If your screen is 25", and you view it from 20' distance, the
>>> down-conversion won't matter.
>> The key word here is "If". When I'm editing audio, it's not
>> background music for me.
> No matter how good your intentions are, human ear is not able to here
> some things.
I don't care about your ear or your agenda.
>>> Likewise for audio - downconversion produces
>>> no audible effect as far as the target format is CD-or-better.
>> And you really think that everybody agrees with you on that?
> And do you really think that "everybody agreeing with me" is a
> meaningful metric?
You didn't answer the question.
> A double-blind test from a trustworthy source
> with no meaningful critique following it is enough.
A single test, is that all? You really think that one person
is representative of all people?
> Hope this helps,
Not even close.
tho...@antispam.ham
> James J. Weinkam <j...@cs.sfu.ca> wrote:
>> Changing sampling rate without introducing distortion is possible but the
>> computation required is complicated and time consuming.
> The computational requirement is addition of two 24-bit quantities.
> So it is neither complicated nor time consuming.
I suggest that you talk to the person who wrote the plug-in for Audacity
to school that person on sampling rate conversion. According to you,
there is no need to choose between "fast" and "good", because the
computational requirement is neither complicated nor time consuming.
I can just see you picking every other sample and saying the original
96 kHz recording is now 48 kHz.
Marty
The bottom line is that any time you're changing the resolution of an
audio waveform, you're inadvertently creating new frequencies. If you
take a sample that is 2^24 - 2, you can convert it to 2^16 -1, but
you've just created high frequency "mathematical" noise. If you're
doing this every sample, the noise might accumulate together into its
own periodic waveform which CAN be audible. Good conversion software
can combat this, but it takes CPU time to do so. You have to
increasingly refine the waveform with Fourier equations - higher orders
of magnitude to improve the quality. If you can just render the sound
in its original format, then you don't have to worry about this.
Ilya Zakharevich
> You seem to be confusing converting from 24 to 16 bit sample size with
> converting from 96 (or 48)KHz and 44.1KHz sample rate.
No.
> The latter is more complicated than the former.
Sure. But what I was replying to was about number of bits, not number
of samples.
Thanks anyway,
Ilya
Ilya Zakharevich
>> If the API accepts it, you do not care about "any other link" of the
>> system.
> Nonsense. Just because an API supports long filenames, for example,
> doesn't mean that you can write a long filename to a FAT16 floppy
> disk.
BS again: I can write a long filename to a FAT16 floppy disk. (Some
*broken implementations* of this API won't be able to do this. But
even in this case they WON'T ACCEPT your request.)
>> It is the task of the API implementation to handle the data
>> so the user can hear it.
>
> Then the API would need to make assumptions about what the
> hardware can handle.
Sure; but this is the API implementation's business, nor yours.
> I'm aware that your statement is complete BS, given that VGA offers
> only 640x480 resolution, which means it's physical impossible to
> display a full 4000x3000 pixel image.
Whatever you say; but *I* do it all the time. My monitor is only
1920x1200; my photos are about 10Kx6K; but I have no problem with
viewing them on my monitor.
>> Frankly speaking, when I view images, I do not care much about the
>> intent of the original creator.
> What if the original creator happens to be yourself? Are you saying
> that you don't care about your own intent?
When I view them - no, I do not care what was my intent when I shot
them. The proof is in the eating...
>> They are proven wrong again and again by double-blind testing - but
>> why should they care?
> Some are proven wrong, and some are proven right. The quality of
> microphone cable matters.
This is about as informative as to say that quality of speakers
matters. Mikes operate with majorly low levels of signals.
[... For less obviousl examples: the quality of SP-DIF cable matters
(at least with lousy phase-locking implementations); but this is an
extremely badly designed interface...]
> Well, my agenda is more important to me than your agenda, so why
> don't you just answer the question, if you know the answer, or
> just leave the thread?
This is not how Usenet works...
>> Sure. So you are measuring one type of conversion vs another one, not
>> conversion vs no-conversion.
> One consumes considerably more CPU time than the other. I don't
> want to put up with the CPU intensive method.
Your wish notwithstanding, you will anyway. (*If* you consider 1% CPU
load as "intensive".)
>>> And you really think that everybody agrees with you on that?
>> And do you really think that "everybody agreeing with me" is a
>> meaningful metric?
> You didn't answer the question.
Hmm, if you want it to be put in plain words: there is a lot of
ignorant people; I do not expect them to agree with anything,
including me. However, I DO NOT THINK about these matters. Does THIS
answer your question?
>> A double-blind test from a trustworthy source
>> with no meaningful critique following it is enough.
> A single test, is that all? You really think that one person
> is representative of all people?
One test vs no tests? Yes, I would take one test.
And if you know what "one test" means, you won't equate it with "one
person".
Hope this helps,
Ilya
Ilya Zakharevich
> The bottom line is that any time you're changing the resolution of an
> audio waveform, you're inadvertently creating new frequencies.
You are forgetting that the initial signal has infinite resolution.
So one should compare not
from 16bit [do nothing to obtain] 16bit
with
from 24bit do smart truncation to 16bit
but
analogue ----> stupid truncation to 16bit
with
analogue ----> stupid truncation to 24bit ----> smart truncation to 16bit
The second path can be made less damaging than the first one.
> If you
> take a sample that is 2^24 - 2, you can convert it to 2^16 -1, but
> you've just created high frequency "mathematical" noise. If you're
> doing this every sample, the noise might accumulate together into its
> own periodic waveform which CAN be audible.
*This* is why one should do noise-modulation before truncation. Did
not you read the algorithm?
> Good conversion software
> can combat this, but it takes CPU time to do so. You have to
> increasingly refine the waveform with Fourier equations - higher orders
> of magnitude to improve the quality.
a) There is no "Fourier equation".
b) Looks like you are confusing sampling-frequency transformations
with bit-depth transformations. But even sampling-frequency
transformations with large enough difference of frequencies are cheap.
Hope this helps,
Ilya
Marty
> On 2010-04-19, tho...@antispam.ham <tho...@antispam.ham> wrote:
>>> If the API accepts it, you do not care about "any other link" of the
>>> system.
>
>> Nonsense. Just because an API supports long filenames, for example,
>> doesn't mean that you can write a long filename to a FAT16 floppy
>> disk.
>
> BS again: I can write a long filename to a FAT16 floppy disk. (Some
> *broken implementations* of this API won't be able to do this. But
> even in this case they WON'T ACCEPT your request.)
This illustrates the problem pretty well though. Let's say you use OS/2
to write a long filename to a disk, with the intent of using this same
disk on a DOS or Win32 machine. What does the long filename look like
there? It is "distorted" (truncated usually, but uniquified) from the
view of this other machine. It is clearly not preserved in its original
form to all those who behold it. So the intended audience is VERY
relevant, as it is in this case with the audio data.
--
[Reverse the parts of the e-mail address to reply.]
Marty
> On 2010-04-19, Marty <n...@comcast.martyamodeo> wrote:
>> The bottom line is that any time you're changing the resolution of an
>> audio waveform, you're inadvertently creating new frequencies.
>
> You are forgetting that the initial signal has infinite resolution.
From an analog source, yes. If your source is a 24-bit audio file on
disk, the resolution is quite limited and well-defined. That is the
case here, unless I misunderstood David.
> So one should compare not
>
> from 16bit [do nothing to obtain] 16bit
> with
> from 24bit do smart truncation to 16bit
>
> but
>
> analogue ----> stupid truncation to 16bit
> with
> analogue ----> stupid truncation to 24bit ----> smart truncation to 16bit
How is this relevant to David playing a 24-bit audio file on his hard disk?
> The second path can be made less damaging than the first one.
Agreed, but not relevant to this situation.
>> If you
>> take a sample that is 2^24 - 2, you can convert it to 2^16 -1, but
>> you've just created high frequency "mathematical" noise. If you're
>> doing this every sample, the noise might accumulate together into its
>> own periodic waveform which CAN be audible.
>
> *This* is why one should do noise-modulation before truncation. Did
> not you read the algorithm?
If nothing else is changing other than the "bitness" of the samples,
what does noise modulation do for you before adjusting the "bitness"?
>> Good conversion software
>> can combat this, but it takes CPU time to do so. You have to
>> increasingly refine the waveform with Fourier equations - higher orders
>> of magnitude to improve the quality.
>
> a) There is no "Fourier equation".
Likely you know what I meant. If not (it's been some years for me,
granted), you're using Fourier transforms to create new coefficients for
higher and higher orders of x such that F(x) more closely approximates
the real values of Y. F(x) has "infinite resolution", but is not an
exact match to your waveform data. The more terms you add to F(x), the
closer it can match your waveform data, and the better it will be at
choosing an appropriate intermediate value that is not in your existing
data set. More terms = more CPU power.
> b) Looks like you are confusing sampling-frequency transformations
> with bit-depth transformations. But even sampling-frequency
> transformations with large enough difference of frequencies are cheap.
I'm not confusing them at all. Both can cause this kind of distortion.
Refer to my example with the 2^24 - 2 sample above. If you draw it
out and "zoom" way in to the point where you can see big chunky boxes,
it's clear to see that the slopes of the lines become different, simply
because the vertical resolution changed.
Lars Erdmann
Kind of. The MMIO offers a command to check if a given audio format is supported or not. That query will obviously go against the audio device driver which in turn should reflect the Audio HW.
If the audio format is supported, it returns with MCIERR_SUCCESS, else it returns with an error.
Here some sample code to explicitely query the WAVE audio device for playing the suggested wave format (I guess that is what you are looking for):
ULONG ulRC;
MCI_OPEN_PARMS mciOpenParms;
MCI_WAVE_GETDEVCAPS_PARMS mciAudioCaps;
memset(&mciOpenParms,0,sizeof(mciOpenParms));
mciOpenParms.pszDeviceType = (PSZ)MAKEULONG(MCI_DEVTYPE_WAVEFORM_AUDIO,0);
ulRC = mciSendCommand(0,
MCI_OPEN,
MCI_WAIT | MCI_OPEN_TYPE_ID,
&mciOpenParms,
0);
if (LOUSHORT(ulRC) == MCIERR_SUCCESS)
{
// audio device could be opened
memset(&mciAudioCaps,0,sizeof(mciAudioCaps);
mciAudioCaps.ulBitsPerSample = 8;
mciAudioCaps.ulFormatTag = DATATYPE_WAVEFORM;
mciAudioCaps.ulSamplesPerSec = 11025;
mciAudioCaps.ulChannels = 1; // check for mono, would be 2 for stereo
mciAudioCaps.ulFormatMode = MCI_PLAY; // check for playing, would be MCI_RECORD for recording caps.
mciAudioCaps.ulItem = MCI_GETDEVCAPS_WAVE_FORMAT;
ulRC = mciSendCommand(mciOpenParms.usDeviceID,
MCI_GETDEVCAPS,
MCI_WAIT | MCI_GETDEVCAPS_EXTENDED | MCI_GETDEVCAPS_ITEM,
&mciAudioCaps,
0);
if (LOUSHORT(ulRC) == MCIERR_SUCCESS)
{
// format is supported
}
else
{
// format is not supported
}
Strategy 1:
You will therefore need to do "trial and error" to find the "maximum" of what the audio device supports.
Strategy 2:
for a given data file, you can use that to attempt to open a device that would play that file. If no capable device is found MMIO would return with an error on MCI_OPEN.
You will open the data file with mmioOpen, feed the mmio Handle to MCI_OPEN like this:
MMIOINFO mmioInfo;
memset(mmioInfo,0,sizeof(mmioInfo));
mmioInfo.ulTranslate = MMIO_TRANSLATEHEADER | MMIO_TRANSLATEDATA); // maybe not, to experiment
hmmio = mmioOpen(wavInputFile,&mmioInfo,MMIO_READ|MMIO_DENYNONE);
memset(&mciOpenParms,0,sizeof(mciOpenParms));
mciOpenParms.pszElementName = (PSZ)hmmio;
mciOpenParms.pszDeviceType = (PSZ)MAKEULONG(MCI_DEVTYPE_WAVEFORM_AUDIO,0);
ulRC = mciSendCommand(0,
MCI_OPEN,
MCI_WAIT | MCI_OPEN_MMIO | MCI_OPEN_TYPE_ID,
&mciOpenParms,
0);
Look here:
"Multimedia Application Programming Guide"->Waveform Audio Device->Audio Device Capabilities
and here:
"Multimedia Programming Reference"->MCI Command Messages->MCI_GET_DEVCAPS / MCI_OPEN
Lars
tho...@antispam.ham
> No.
You just contradicted yourself. For a given recording time, the
number of samples depends on the sampling rate, but you just
finished saying that you didn't confuse your example about bit
depth with sampling rate.
tho...@antispam.ham
>>> If the API accepts it, you do not care about "any other link" of the
>>> system.
>> Nonsense. Just because an API supports long filenames, for example,
>> doesn't mean that you can write a long filename to a FAT16 floppy
>> disk.
> BS again: I can write a long filename to a FAT16 floppy disk.
I'm aware that your statement is BS again. Sure, you can write a
long filename to a file that itself is named with a short filename,
but that's not the same thing.
> (Some
> *broken implementations* of this API won't be able to do this. But
> even in this case they WON'T ACCEPT your request.)
As I already said, the API would need to make assumptions about
what the hardware can handle.
>>> It is the task of the API implementation to handle the data
>>> so the user can hear it.
>> Then the API would need to make assumptions about what the
>> hardware can handle.
> Sure; but this is the API implementation's business, nor yours.
Nonsense; anyone who writes code to use that API needs to know about
all possible return values, including error returns where the API
wasn't able to complete the request. A programmer cannot blindly
proceed on the basis that the API can handle all possibilities.
>> I'm aware that your statement is complete BS, given that VGA offers
>> only 640x480 resolution, which means it's physical impossible to
>> display a full 4000x3000 pixel image.
> Whatever you say; but *I* do it all the time.
No, you don't.
> My monitor is only
> 1920x1200; my photos are about 10Kx6K; but I have no problem with
> viewing them on my monitor.
No doubt you also tell people that they don't need a wide-screen
television to watch high definition content. After all, some people
do it on their standard definition televisions all the time, without
any "problem".
>>> Frankly speaking, when I view images, I do not care much about the
>>> intent of the original creator.
>> What if the original creator happens to be yourself? Are you saying
>> that you don't care about your own intent?
> When I view them - no, I do not care what was my intent when I shot
> them. The proof is in the eating...
I know some movie directors who would disagree with you rather
violently. Seeing one person's reaction to what another person
is saying is absolutely crucial to some director's intent, but
if the movie is being shown in pan and scan mode such that only
one person's face can be seen at any one time, you're out of
luck.
>>> They are proven wrong again and again by double-blind testing - but
>>> why should they care?
>> Some are proven wrong, and some are proven right. The quality of
>> microphone cable matters.
> This is about as informative as to say that quality of speakers
> matters. Mikes operate with majorly low levels of signals.
And speakers operate with considerably more power, which means
that speaker cable that is too thin can have audible effects on
the music. In other words, speaker cable does matter. That
doesn't mean that overkill isn't possible.
> [... For less obviousl examples: the quality of SP-DIF cable matters
> (at least with lousy phase-locking implementations); but this is an
> extremely badly designed interface...]
You've just invalidated your own example. As I said before, sometimes
it matters, sometimes it doesn't. Why do you think some people buy
CAT5 ethernet cable? Do you advise them that ethernet cable is ethernet
cable, that CAT3 is as good as CAT5?
>> Well, my agenda is more important to me than your agenda, so why
>> don't you just answer the question, if you know the answer, or
>> just leave the thread?
> This is not how Usenet works...
Obviously. So what's your agenda? You like making a fool of
yourself on Usenet like so many others?
>>> Sure. So you are measuring one type of conversion vs another one, not
>>> conversion vs no-conversion.
>> One consumes considerably more CPU time than the other. I don't
>> want to put up with the CPU intensive method.
> Your wish notwithstanding, you will anyway. (*If* you consider 1% CPU
> load as "intensive".)
Once again, the key word here is "if". You obviously don't know
much about sampling rate converion.
>>>> And you really think that everybody agrees with you on that?
>>> And do you really think that "everybody agreeing with me" is a
>>> meaningful metric?
>> You didn't answer the question.
> Hmm, if you want it to be put in plain words: there is a lot of
> ignorant people; I do not expect them to agree with anything,
> including me. However, I DO NOT THINK about these matters. Does THIS
> answer your question?
No, it doesn't. That much should be obvious.
>>> A double-blind test from a trustworthy source
>>> with no meaningful critique following it is enough.
>> A single test, is that all? You really think that one person
>> is representative of all people?
> One test vs no tests? Yes, I would take one test.
And suppose the one test is about color television being better than
black and white television, but you got a color-blind person in the
test?
> And if you know what "one test" means, you won't equate it with "one
> person".
That's pretty funny, coming from someone who offered 1% as being
CPU intensive.
tho...@antispam.ham
> Marty <n...@comcast.martyamodeo> wrote:
>> The bottom line is that any time you're changing the resolution of an
>> audio waveform, you're inadvertently creating new frequencies.
> You are forgetting that the initial signal has infinite resolution.
> So one should compare not
>
> from 16bit [do nothing to obtain] 16bit
> with
> from 24bit do smart truncation to 16bit
>
> but
>
> analogue ----> stupid truncation to 16bit
> with
> analogue ----> stupid truncation to 24bit ----> smart truncation to 16bit
>
> The second path can be made less damaging than the first one.
Once again, you're confusing bit depth with sampling rate conversion.
Marty was clearly talking about sampling rate conversion, yet here
you are once again trying to counter his argument by talking about
bit depth. Obviously you don't know what you're talking about. Why
not quit while you're behind? Or do you really enjoy digging yourself
deeper and deeper into the hole you're in?
>> If you
>> take a sample that is 2^24 - 2, you can convert it to 2^16 -1, but
>> you've just created high frequency "mathematical" noise. If you're
>> doing this every sample, the noise might accumulate together into its
>> own periodic waveform which CAN be audible.
> *This* is why one should do noise-modulation before truncation. Did
> not you read the algorithm?
Which algorithm are you talking about? You bit depth algorithm? Hardly
applicable to a sampling rate conversion.
>> Good conversion software
>> can combat this, but it takes CPU time to do so. You have to
>> increasingly refine the waveform with Fourier equations - higher orders
>> of magnitude to improve the quality.
> a) There is no "Fourier equation".
Nonsense.
> b) Looks like you are confusing sampling-frequency transformations
> with bit-depth transformations.
No, you are the one who is confused. James noted that "Changing
sampling rate without introducing distortion is possible but the
computation required is complicated and time consuming." You
countered that it was neither complicated nor time consuming, and
that's when Marty stepped and noted that when you change the
resolution of an audio waveform, you're inadvertently creating new
frequencies, which is exactly what happens when the sampling rate
is reduced.
> But even sampling-frequency
> transformations with large enough difference of frequencies are cheap.
Define "cheap". Only 1 ms delay? Only 1% CPU load?
tho...@antispam.ham
> Ilya Zakharevich wrote:
>>> Good conversion software
>>> can combat this, but it takes CPU time to do so. You have to
>>> increasingly refine the waveform with Fourier equations - higher orders
>>> of magnitude to improve the quality.
>> a) There is no "Fourier equation".
> Likely you know what I meant.
Don't count on it. He is unaware that a 96 kHz signal preserves
frequencies to 48 kHz, which will alias with other frequencies
when the sampling rate is down converted to 44.1 kHz. It's a
well-known fact that the 96 kHz signal needs to be band limited
to 44.1 kHz before performing the sampling rate conversion, and
the usual way of doing that is with a Fourier transform.
tho...@antispam.ham
>> Are there ways to query a system with regard to its audio
>> capabilities? I'm thinking of something analogous to the ways
>> one can query a system with regard to its video capabilities,
>> such as horizontal and vertical resolution and bit depth. Is
>> there anything like that for audio capabilities?
>>
>> Presumably a system can do no better than its weakest link,
>> and in the case of an OS/2 computer, one would think that the
>> links include the capabilities of the sound card hardware, the
>> capabilities of the sound card driver, the capabilities of the
>> operating system, and lastly the capabilities of the application
>> software. For example, I can write my audio editing application
>> software to handle 24-bit/96 kHz .WAV files, but I can't play
>> them unless the sound card, the driver for it, and the operating
>> system all support it. Does anyone know what OS/2 itself
>> supports regarding bit depth and sampling rate? How about the
>> UNIAUD driver?
> Kind of. The MMIO offers a command to check if a given audio
> format is supported or not. That query will obviously go against
> the audio device driver which in turn should reflect the Audio HW.
> If the audio format is supported, it returns with MCIERR_SUCCESS,
> else it returns with an error.
That's the sort of thing I'm looking for! Thanks for being a ray
of sunshine on this question.
If a sound card vendor supplies both the hardware and the software
driver for the hardware, then yes, I would expect the device driver
to reflect the hardware. But what about UNIAUD? Like with the
SNAP video driver, there were some newer chipsets that were similar
to older supported chipsets, and SNAP might work with them, at
least partially. I suppose it's reasonable to assume that newer
hardware would be at least as capable as older hardware, so it
wouldn't be like the driver supporting a high resolution mode that
the card wouldn't support.
Theoretically speaking, if some vendor were to produce a high
resolution audio card and also supply an OS/2 driver for it,
might we then run into some limitation imposed by the operating
system itself? Or is OS/2 pretty agnostic when it comes to
bit depth and sampling rate for audio?
tho...@antispam.ham
>> Nonsense; I can and have written code that can deal with 24-bit
>> 96 kHz .WAV files. That's the strongest link. Doesn't do me
>> any good, because the rest of the system doesn't support the
>> playing of 24-bit 96 kHz .WAV files, but I don't know whether
>> it's the hardware (sound card), the driver for it, or the
>> operating system that is the limiting factor, namely the weak
>> link. Nor do I know what the limits of the system are. That's
>> why I'm looking for a way to query the capabilities of a system.
> I have a Creative Labs Soundblaster Audigy 4 24 bit sound card. The uniaud
> drivers will play 16 bit, 44100 stereo wav files as well as a variety of lower
> sampling rates and sample sizes with suitable software, but at present they do
> not support playback at higher sampling rates or sizes or recording.
>
> The windows software and drivers that came with the card fully support all its
> features for recording and playback; however attempts to edit or convert from
> 24 to 16 bits either crash the system or result in corrupt wav files for
> recordings of any size.
Crash the system when running Windows? Or crash OS/2 when trying to run
them via Odin? Crashing when running under Windows doesn't speak well for
Creative Labs.
> I record live performances of the Senior Vancouver Youth Symphony Orchestra in
> theaters such as the Michael J. Fox theater or the Kay Meek Center at 24-44100
> using a stereo point microphone. I convert to 16-44100 wav files in eCS using
> editing software I wrote myself. The resulting cd's are indistinguishable from
> commercial cd's.
I've got a bunch of recordings from the days of Digital Audio Tape,
where the sampling rate is 48 kHz, so to convert them to CD format,
I'll need to perform a sampling rate conversion. In the past, that
has been handled automatically when transfering the recording from
DAT to CD using a Philips standalone audio CD recorder, but if I
ever have the equipment to read the DATs directly into a computer,
then I'll need to perform the sampling rate conversion myself.
Recent recordings have been made directly to flash memory, usually at
44.1 kHz, but the most recent recordings have been made in pairs, one
recorder running at 44.1 kHz and another at 96 kHz. I can, of course,
listen to the 96 kHz recording on the recorder itself, but not in my
audio editing software.
> So the answer to your question is that it is probably the drivers. The
> difficulty is writing software to operate the card is that the the ICOTL
> interface is inaccurately and incompletely documented. The command line mixer
> application that comes with uniaud is buggy and is only able to set some of
> the controls. I don't recall the exact details, since it has been a couple of
> years since I messed with it,
>
> Carsten Arnold's playrec works for playback but not for recording.
> Unfortunately he is no longer maintaining the program.
I need the playback capability that is built right into my editing software.
I listen to small snippets, say 0.2 or 0.3 seconds in length to find when a
note begins (such as at the very beginning of a piece), incrementing one
of the limits by 0.01 sec for each press of the cursor key. Works well, but
playback really needs to be built in to my editing software. I can do that
for CD resolution, but not 24-bit 96 kHz.
tho...@antispam.ham
> Marty wrote:
If the recording level is set appropriately, such that the loudest passages
are approaching 0 dBFS, then I suppose the quick and dirty way to reduce
the bit depth would be to simply ignore the 8 least significant bits. If
you need to grab the 16 bits somewhere in the middle of the 24 bits, then
life is a little more difficult.
Lars Erdmann
> Lars Erdmann <lars.e...@arcor.de> writes:
>
>
> If a sound card vendor supplies both the hardware and the software
> driver for the hardware, then yes, I would expect the device driver
> to reflect the hardware. But what about UNIAUD? Like with the
> SNAP video driver, there were some newer chipsets that were similar
> to older supported chipsets, and SNAP might work with them, at
> least partially. I suppose it's reasonable to assume that newer
> hardware would be at least as capable as older hardware, so it
> wouldn't be like the driver supporting a high resolution mode that
> the card wouldn't support.
>
> Theoretically speaking, if some vendor were to produce a high
> resolution audio card and also supply an OS/2 driver for it,
> might we then run into some limitation imposed by the operating
> system itself? Or is OS/2 pretty agnostic when it comes to
> bit depth and sampling rate for audio?
The OS will not impose any limitation.
The multimedia interface is pretty complex. The low level audio PDD (uniaud16.sys) only moves bytes streams to/from the audio HW.
But other components (audiomcd.dll or a replacement for it) describe the driver capabilities.
That said, I believe that the standard audiomcd.dll that comes with OS/2 is limited to 44kHz, 16-bit stereo. However, a sound card driver creator can also
provide a replacement for audiomcd.dll. Therefore, the multimedia interface is widen open for extensions and additional features.
If you really want to dig into it, you will need to read the "Multimedia ..." references. Looking at DDK sample code will also be helpful.
Lars
tho...@antispam.ham
>> Theoretically speaking, if some vendor were to produce a high
>> resolution audio card and also supply an OS/2 driver for it,
>> might we then run into some limitation imposed by the operating
>> system itself? Or is OS/2 pretty agnostic when it comes to
>> bit depth and sampling rate for audio?
> The OS will not impose any limitation.
> The multimedia interface is pretty complex. The low level audio
> PDD (uniaud16.sys) only moves bytes streams to/from the audio HW.
> But other components (audiomcd.dll or a replacement for it)
> describe the driver capabilities.
> That said, I believe that the standard audiomcd.dll that comes
> with OS/2 is limited to 44kHz, 16-bit stereo. However, a sound
> card driver creator can also provide a replacement for audiomcd.dll.
> Therefore, the multimedia interface is widen open for extensions
> and additional features.
My system will play 48 kHz .WAV files, but it's unclear whether
that's because of the standard audiomcd.dll or the one provided
for the Analog Devices audio chipset.
> If you really want to dig into it, you will need to read the
> "Multimedia ..." references. Looking at DDK sample code will
> also be helpful.
Maybe someday.
Ilya Zakharevich
[Wrong irrelevant info about FAT16 omitted.]
>>>> It is the task of the API implementation to handle the data
>>>> so the user can hear it.
>>> Then the API would need to make assumptions about what the
>>> hardware can handle.
>> Sure; but this is the API implementation's business, nor yours.
> Nonsense; anyone who writes code to use that API needs to know about
> all possible return values, including error returns where the API
> wasn't able to complete the request. A programmer cannot blindly
> proceed on the basis that the API can handle all possibilities.
You still do not understand the situation: so I'll explain it to you in
short words (if the concept of virtualization is so hard to understand):
there is a sound card allowing input in formats A1, A2, etc;
there is a sound API library; this library supports input in formats
B1, B2, etc. The implemenation of this API (together with some
parts of OS and the drivers) knows about the details of the sound
card, and knows how it needs to massage the input formats so that
they can be played by the sound card.
Ergo: the users of the API cares about whether they can massage their
input data into formats B1, B2, .... And they care none at all about
formats A1, A2, ....
>> Whatever you say; but *I* do it all the time.
>
> No, you don't.
Good that you know what I do better than me. Nice to know that people
care about you... ;-)
> No doubt you also tell people that they don't need a wide-screen
> television to watch high definition content.
Sure.
>> This is about as informative as to say that quality of speakers
>> matters. Mikes operate with majorly low levels of signals.
> And speakers operate with considerably more power, which means
> that speaker cable that is too thin can have audible effects on
> the music.
You are right - I should have made an exception for the wire's gauge.
>> [... For less obviousl examples: the quality of SP-DIF cable matters
>> (at least with lousy phase-locking implementations); but this is an
>> extremely badly designed interface...]
>
> You've just invalidated your own example. As I said before, sometimes
> it matters, sometimes it doesn't.
Sure. Some things are red, some are blue. What is relevant is that
anything above 44K/16bit does not matter...
>> Does THIS
>> answer your question?
> No, it doesn't. That much should be obvious.
It was obvious to me that it does. Next time, formulate your
questions better.
Hope this helps,
Ilya
Ilya Zakharevich
>> You are forgetting that the initial signal has infinite resolution.
>
> From an analog source, yes. If your source is a 24-bit audio file on
> disk, the resolution is quite limited and well-defined. That is the
> case here, unless I misunderstood David.
No, the discussion was about 16 bit source vs 24 bit source.
> How is this relevant to David playing a 24-bit audio file on his hard disk?
I do not know who is this "David"; I was answering something for which
it was relevant...
>> *This* is why one should do noise-modulation before truncation. Did
>> not you read the algorithm?
> If nothing else is changing other than the "bitness" of the samples,
> what does noise modulation do for you before adjusting the "bitness"?
It removes "the defects" of rounding - i.e., the correlation between
the initial signal and rounding errors. [Somewhat similar to
filtering out the high frequencies before downsampling, so that they
do not alias to low frequencies.]
>>> Good conversion software
>>> can combat this, but it takes CPU time to do so. You have to
>>> increasingly refine the waveform with Fourier equations - higher orders
>>> of magnitude to improve the quality.
>>
>> a) There is no "Fourier equation".
> Likely you know what I meant.
I have no idea. [To downsample, all one needs is a low-pass filter,
which is not CPU-intensive.]
> If not (it's been some years for me,
> granted), you're using Fourier transforms to create new coefficients for
> higher and higher orders of x such that F(x) more closely approximates
> the real values of Y. F(x) has "infinite resolution", but is not an
> exact match to your waveform data. The more terms you add to F(x), the
> closer it can match your waveform data, and the better it will be at
> choosing an appropriate intermediate value that is not in your existing
> data set. More terms = more CPU power.
Does not make much sense to me, sorry... The actual theory behind all
this is pretty elementary - nothing as convoluted as what you attempt
to write...
>> b) Looks like you are confusing sampling-frequency transformations
>> with bit-depth transformations. But even sampling-frequency
>> transformations with large enough difference of frequencies are cheap.
> I'm not confusing them at all. Both can cause this kind of distortion.
> Refer to my example with the 2^24 - 2 sample above. If you draw it
> out and "zoom" way in to the point where you can see big chunky boxes,
> it's clear to see that the slopes of the lines become different, simply
> because the vertical resolution changed.
Have no idea what you are trying to convey here...
Yours,
Ilya
Ilya Zakharevich
>> with bit-depth transformations.
> No, you are the one who is confused. James noted that "Changing
> sampling rate without introducing distortion is possible but the
> computation required is complicated and time consuming."
Might be. However, if you actually pay attention to what I was
replying to, it was
If your original recording is 16 bit stereo, you are not subject
to the errors introduced by the reduced resolution. A sample that
was originally 24 bits however, could become a less "perfect" 16
bit sample than it would have been if it was recorded at 16 bit
resolution from the beginning.
>> But even sampling-frequency
>> transformations with large enough difference of frequencies are cheap.
>
> Define "cheap". Only 1 ms delay? Only 1% CPU load?
I would say about 20 samples delay. And as CPU load goes, 5% CPU load
with today's non-on-the-bleeding-edge CPUs is on the cheap side.
Hope this helps,
Ilya
Ilya Zakharevich
> driver for the hardware, then yes, I would expect the device driver
> to reflect the hardware.
Almost never, AFAIK. E.g., I vaguely remember one of the SB cards
ALWAYS running at 48kHz - but the driver would accept almost any
sampling frequency.
Likewise: SB Live IIRC can play many sources simultaneously - each at
its own sampling rate and bit depth...
Hope this helps,
Ilya
tho...@antispam.ham
> [Wrong irrelevant info about FAT16 omitted.]
You're very good at making claims that something is wrong, but
lousy at providing any supporting evidence, which means that the
claim can be safely ignored.
>>>>> It is the task of the API implementation to handle the data
>>>>> so the user can hear it.
>>>> Then the API would need to make assumptions about what the
>>>> hardware can handle.
>>> Sure; but this is the API implementation's business, nor yours.
>> Nonsense; anyone who writes code to use that API needs to know about
>> all possible return values, including error returns where the API
>> wasn't able to complete the request. A programmer cannot blindly
>> proceed on the basis that the API can handle all possibilities.
> You still do not understand the situation:
On the contrary, you are the one who doesn't understand the situation.
The situation is this: is there a way to query a system with regard
to its audio capabilities? Lars provided both an answer and some
sample code. All we've had from you are claims that the capabilities
don't matter, because you can convert to something that works using
code that isn't complex and isn't time consuming, which demonstrates
just how poorly you understand the situation.
> so I'll explain it to you in
> short words (if the concept of virtualization is so hard to understand):
It was my question, therefore it is my situation, which I have already
explained. You trying to explain your agenda is irrelevant.
> there is a sound card allowing input in formats A1, A2, etc;
I want a list of A1, A2, etc.
> there is a sound API library; this library supports input in formats
> B1, B2, etc. The implemenation of this API (together with some
> parts of OS and the drivers) knows about the details of the sound
> card,
I want to know the details of the sound card.
> and knows how it needs to massage the input formats so that
> they can be played by the sound card.
Unacceptable. I want to know that a change in the sound is due to
my code, not due to some driver's massaging.
> Ergo: the users of the API cares about whether they can massage their
> input data into formats B1, B2, .... And they care none at all about
> formats A1, A2, ....
Nonsense. But as predicted, you demonstrated that you don't understand
the situation.
>>> Whatever you say; but *I* do it all the time.
>> No, you don't.
> Good that you know what I do better than me. Nice to know that people
> care about you... ;-)
"If I let go of a hammer on a planet with a positive gravity, I
need not see it fall to know that it has, in fact, fallen." In
other words, I don't need to know you at all when the laws of
physics take precedence.
>> No doubt you also tell people that they don't need a wide-screen
>> television to watch high definition content.
> Sure.
Figures.
>>> This is about as informative as to say that quality of speakers
>>> matters. Mikes operate with majorly low levels of signals.
>> And speakers operate with considerably more power, which means
>> that speaker cable that is too thin can have audible effects on
>> the music.
> You are right - I should have made an exception for the wire's gauge.
More than just the gauge. The two microphone cables have comparable
gauges, yet one doesn't work properly with phantom-powered microphones.
>>> [... For less obviousl examples: the quality of SP-DIF cable matters
>>> (at least with lousy phase-locking implementations); but this is an
>>> extremely badly designed interface...]
>> You've just invalidated your own example. As I said before, sometimes
>> it matters, sometimes it doesn't.
> Sure. Some things are red, some are blue. What is relevant is that
> anything above 44K/16bit does not matter...
Then why don't you try to convince all those manufacturers who are
selling recorders with modes above 44K/16bit that they're unnecessary?
Afraid of being laughed at?
>>> Does THIS
>>> answer your question?
>> No, it doesn't. That much should be obvious.
> It was obvious to me that it does.
Wouldn't be the first time you've hallucinated.
> Next time, formulate your questions better.
My question was formulated just fine. Lars didn't have any trouble
answering.
tho...@antispam.ham
> Marty wrote:
>>> You are forgetting that the initial signal has infinite resolution.
>> From an analog source, yes. If your source is a 24-bit audio file on
>> disk, the resolution is quite limited and well-defined. That is the
>> case here, unless I misunderstood David.
> No, the discussion was about 16 bit source vs 24 bit source.
Wrong again. The discussion was about a way to query a system regarding
its audio capabilities. It's nice to know if a system can play a 24-bit
96 kHz .WAV file before you needlessly go through the trouble of converting
it to a different format.
>> How is this relevant to David playing a 24-bit audio file on his hard disk?
> I do not know who is this "David"; I was answering something for which
> it was relevant...
You weren't answering the question asked. You were simply trying to
impose your agenda regarding the audibility of higher resolution formats.
>>> *This* is why one should do noise-modulation before truncation. Did
>>> not you read the algorithm?
>> If nothing else is changing other than the "bitness" of the samples,
>> what does noise modulation do for you before adjusting the "bitness"?
> It removes "the defects" of rounding - i.e., the correlation between
> the initial signal and rounding errors. [Somewhat similar to
> filtering out the high frequencies before downsampling, so that they
> do not alias to low frequencies.]
Not at all similar. Not even remotely. Which further demonstrates
that you don't understand the situation.
>>>> Good conversion software
>>>> can combat this, but it takes CPU time to do so. You have to
>>>> increasingly refine the waveform with Fourier equations - higher orders
>>>> of magnitude to improve the quality.
>>> a) There is no "Fourier equation".
>> Likely you know what I meant.
> I have no idea. [To downsample, all one needs is a low-pass filter,
> which is not CPU-intensive.]
Interesting to see you start talking about low-pass filters and aliasing
only AFTER it was brought up by me as further evidence that you don't
understand the situation. But no, you need more than just a low-pass
filter. You also need an interpolator, unless you are converting by a
factor of 2. Note the converting from 96 kHz to 44.1 kHz is not a
simple factor of 2.
>> If not (it's been some years for me,
>> granted), you're using Fourier transforms to create new coefficients for
>> higher and higher orders of x such that F(x) more closely approximates
>> the real values of Y. F(x) has "infinite resolution", but is not an
>> exact match to your waveform data. The more terms you add to F(x), the
>> closer it can match your waveform data, and the better it will be at
>> choosing an appropriate intermediate value that is not in your existing
>> data set. More terms = more CPU power.
> Does not make much sense to me, sorry...
That's been obvious for some time.
> The actual theory behind all this is pretty elementary
Hardly.
> - nothing as convoluted as what you attempt to write...
Further evidence that you don't understand the situation.
>>> b) Looks like you are confusing sampling-frequency transformations
>>> with bit-depth transformations. But even sampling-frequency
>>> transformations with large enough difference of frequencies are cheap.
>> I'm not confusing them at all. Both can cause this kind of distortion.
>> Refer to my example with the 2^24 - 2 sample above. If you draw it
>> out and "zoom" way in to the point where you can see big chunky boxes,
>> it's clear to see that the slopes of the lines become different, simply
>> because the vertical resolution changed.
> Have no idea what you are trying to convey here...
No wonder you're having such trouble understanding the situation.
tho...@antispam.ham
>>> b) Looks like you are confusing sampling-frequency transformations
>>> with bit-depth transformations.
>> No, you are the one who is confused. James noted that "Changing
>> sampling rate without introducing distortion is possible but the
>> computation required is complicated and time consuming."
> Might be.
In your previous posting, you claimed that the actual theory is
pretty elementary. Now you're admitting that it might be complicated?
Do make up your mind.
> However, if you actually pay attention to what I was
> replying to, it was
You're the one who hasn't been paying attention, given that you've
confused bit-depth conversion with sampling rate conversion TWICE
now.
> If your original recording is 16 bit stereo, you are not subject
> to the errors introduced by the reduced resolution.
Your statement is ambiguous. There is signal strength resolution
(bit depth) and temporal resolution (sampling rate).
> A sample that
> was originally 24 bits however, could become a less "perfect" 16
> bit sample than it would have been if it was recorded at 16 bit
> resolution from the beginning.
Are you really trying to convince readers that all the manufacturers
offering higher resolution audio recorders are making matters worse?
>>> But even sampling-frequency
>>> transformations with large enough difference of frequencies are cheap.
>> Define "cheap". Only 1 ms delay? Only 1% CPU load?
> I would say about 20 samples delay.
And your estimate is based on how much practical experience?
> And as CPU load goes, 5% CPU load
> with today's non-on-the-bleeding-edge CPUs is on the cheap side.
Well, you've upped your CPU load by a factor of 5. Hedging your
bets, eh?
tho...@antispam.ham
>> If a sound card vendor supplies both the hardware and the software
>> driver for the hardware, then yes, I would expect the device driver
>> to reflect the hardware.
> Almost never, AFAIK. E.g., I vaguely remember one of the SB cards
> ALWAYS running at 48kHz - but the driver would accept almost any
> sampling frequency.
So, you've taken a vague recollection of ONE and translated that into
"almost never". Talk about extrapolation!
> Likewise: SB Live IIRC can play many sources simultaneously - each at
> its own sampling rate and bit depth...
Can it play 24-bit 96 kHz? Oh, that's right; you don't care.
Lars Erdmann
<tho...@antispam.ham> schrieb im Newsbeitrag
news:hqj8n0$db$1...@speranza.aioe.org...
> Lars Erdmann <lars.e...@arcor.de> writes:
>
>> The OS will not impose any limitation.
>> The multimedia interface is pretty complex. The low level audio
>> PDD (uniaud16.sys) only moves bytes streams to/from the audio HW.
>> But other components (audiomcd.dll or a replacement for it)
>> describe the driver capabilities.
>> That said, I believe that the standard audiomcd.dll that comes
>> with OS/2 is limited to 44kHz, 16-bit stereo. However, a sound
>> card driver creator can also provide a replacement for audiomcd.dll.
>> Therefore, the multimedia interface is widen open for extensions
>> and additional features.
>
> My system will play 48 kHz .WAV files, but it's unclear whether
> that's because of the standard audiomcd.dll or the one provided
> for the Analog Devices audio chipset.
I have to correct myself. The audiomcd.dll is also not more than a
passthrough. When you open a device and use the MCI_SET command to set it to
a specific sample rate/bits per sample (or pass it a sound file from where
the sample rate/bits per sample can be gleaned from) an IOCTL call goes to
the audio device driver to initialize a new stream with these settings. If
the audio driver returns with OK, you are then set to use it.
Likewise the MCI_GET_DEVCAPS command I talked about eventually translates
into an IOCTL call that goes to the audio device driver.
Therefore it's all up to the audio device driver to report that the settings
are OK or not.
The limitation is therefore the audio device driver (I am talking about the
real Physical device driver like: UNIAUD16.sys). Ideally the audio device
driver offers everything that the audio HW can support but it might offer
less (just like SNAP might not support every feature of the graphics cards
it supports).
Therefore your audio device driver (is it uniaud16.sys ?) restricts the
sample rate to 48 kHz even though some supported audio chipsets might
support more in HW.
The IOCTL for an audio device driver is documented in the MMPM/2 reference
(part of DDK).
Lars
Ilya Zakharevich
>> You still do not understand the situation:
>
> On the contrary, you are the one who doesn't understand the situation.
> The situation is this: is there a way to query a system with regard
> to its audio capabilities? Lars provided both an answer and some
> sample code.
The info he provided is absolutely irrelevant to your situation: you
claim you already KNOW that your system CAN handle 44.1/16 (and
48/16?), and it is what you are going to use anyway...
> Unacceptable. I want to know that a change in the sound is due to
> my code, not due to some driver's massaging.
So you should have claimed at the start. Then the answer is simple:
you need to look at the tech specs of the sound card.
But anyway, this is irrelevant to your situation. Your input is
96/24; internally, it is quite probable that your sound card's DAC
works ONLY in 96/24. In this case, you WILL downconvert to 48/16, and
the internal hardware WILL upconvert to 96/24 again.
Fortunately, all this won't be noticable...
>> You are right - I should have made an exception for the wire's gauge.
> More than just the gauge. The two microphone cables have comparable
> gauges, yet one doesn't work properly with phantom-powered microphones.
Some people might have noticed I was not discussing mike cable...
> Then why don't you try to convince all those manufacturers who are
> selling recorders with modes above 44K/16bit that they're unnecessary?
> Afraid of being laughed at?
Apparently, you do not understand the difference between recording and
reproduction. Figures...
[And what manufacturer of reproduction equipment are interested is
profit. If it sells, of course it makes a lot of sense to
manufacture it. Is it so hard to understand?]
> My question was formulated just fine. Lars didn't have any trouble
> answering.
A different question... [One I was answering was something like "Do I
think that everybody must agree with me blah blah blah" or somesuch.]
Hope this helps,
Ilya
Ilya Zakharevich
> But no, you need more than just a low-pass
> filter. You also need an interpolator, unless you are converting by a
> factor of 2.
BS. Interpolator == Low pass filter. If you do not understand this,
see works of Mitchell (freely available from his website). He (in
addition to inventing new stuff) was very keen on addressing
misunderstanding like yours...
Hope this helps,
Ilya
James J. Weinkam
>>
>> The windows software and drivers that came with the card fully support all its
>> features for recording and playback; however attempts to edit or convert from
>> 24 to 16 bits either crash the system or result in corrupt wav files for
>> recordings of any size.
>
> Crash the system when running Windows? Or crash OS/2 when trying to run
> them via Odin? Crashing when running under Windows doesn't speak well for
> Creative Labs.
>
Recorder, and a wave file editor called Wave Studio, and no doubt other stuff as well that I don't remember. It is only the latter program that turns
out to be useless. To expand somewhat on what I said previously, if you try to do anything with a large recording (on the order of 45 minutes or more)
performance gets slower and more erratic the more you try to do and saving the "result" usually produces a corrupt wav file and sometimes crashes
Windows. It looks to me as if the program is making the entire file resident in virtual memory; and once the file being edited exceeds some critical
value the system begins to thrash. I have never tried it under Odin.
tho...@antispam.ham
>>> You still do not understand the situation:
>> On the contrary, you are the one who doesn't understand the situation.
>> The situation is this: is there a way to query a system with regard
>> to its audio capabilities? Lars provided both an answer and some
>> sample code.
> The info he provided is absolutely irrelevant to your situation: you
> claim you already KNOW that your system CAN handle 44.1/16 (and
> 48/16?), and it is what you are going to use anyway...
No, it's not what I'm going to use anyway. I'm going to use the
format of the .WAV file, if the sound card supports it. That way
I don't need to do any conversion. But I need to know what the
sound card supports.
>> Unacceptable. I want to know that a change in the sound is due to
>> my code, not due to some driver's massaging.
> So you should have claimed at the start.
My question was a valid question regardless of my motivation for
asking it.
> Then the answer is simple:
> you need to look at the tech specs of the sound card.
Unacceptable. I want my code to work even if somebody else is using
it on their own system with a different sound card.
> But anyway, this is irrelevant to your situation.
Nonsense; it is very relevant.
> Your input is
> 96/24; internally, it is quite probable that your sound card's DAC
> works ONLY in 96/24.
On what do you base that claim? Why not 192 kHz? There are recorders
out there that work at that sampling rate. Indeed, there are some
one-bit recorders that work at MHz sampling rates. What's so magical
about 96/24? My sound card is 7 years old, so it dates from an era
before higher resolution (than the CD standard) became commonplace.
> In this case, you WILL downconvert to 48/16,
Not if the sound card supports 96/24.
> and the internal hardware WILL upconvert to 96/24 again.
On what do you base that claim?
> Fortunately, all this won't be noticable...
Fortunately for you, because you can make all the claims you want to
make with no easy way to prove that you're right or wrong.
>>> You are right - I should have made an exception for the wire's gauge.
>> More than just the gauge. The two microphone cables have comparable
>> gauges, yet one doesn't work properly with phantom-powered microphones.
> Some people might have noticed I was not discussing mike cable...
You were discussing multiple cases of what you consider to be overkill,
like higher resolution (than the CD standard) reproduction methods,
"audiophile" speaker cable, and even HDMI cable. Just because some
people buy more expensive cable than they need doesn't automatically
mean that higher resolution reproduction methods are similarly unneeded.
>> Then why don't you try to convince all those manufacturers who are
>> selling recorders with modes above 44K/16bit that they're unnecessary?
>> Afraid of being laughed at?
> Apparently, you do not understand the difference between recording and
> reproduction. Figures...
On the contrary, I understand it all too well. It's you who still
doesn't understand the situation. I made the recording. I want to
edit it. I don't want to go through the trouble of converting it
every time I play a section to hear the result of an edit. Ideally
the down-conversion to the CD format would be the last step. And I
don't buy your claim that the down-conversion isn't any trouble.
Doing it well takes CPU time, your claims notwithstanding.
> [And what manufacturer of reproduction equipment are interested is
> profit. If it sells, of course it makes a lot of sense to
> manufacture it. Is it so hard to understand?]
Once again, you're trying to make it sound like the only reason
higher resolution reproduction methods exist is because some
manufacturer is making money off of gullible consumers. You are
entitled to your opinion, and your agenda. So am I, but your
hypocrisy about that is getting in the way. I want the higher
resolution reproduction method, and I'm well aware that some
people like you think it's unneeded. Too bad for you that only
my agenda matters to me.
>> My question was formulated just fine. Lars didn't have any trouble
>> answering.
> A different question... [One I was answering was something like "Do I
> think that everybody must agree with me blah blah blah" or somesuch.]
You can't even remember the question, yet you claim it wasn't formulated
well? Talk about baseless claims.
tho...@antispam.ham
>> But no, you need more than just a low-pass
>> filter. You also need an interpolator, unless you are converting by a
>> factor of 2.
> BS. Interpolator == Low pass filter.
I'm well aware that your equation is BS.
> If you do not understand this,
Suppose I want to UP convert from a lower sampling rate to a higher
sampling rate. You still need an interpolator, but it's definitely
not acting as a low pass filter. Obviously they are not the same
thing, contrary to your assertion. Don't bother responding with
some lame assertion that upconversion is totally unnecessary. Lots
of DVD players are being sold today that upconvert standard definition
video to display on a high definition monitor.
> see works of Mitchell (freely available from his website). He (in
> addition to inventing new stuff) was very keen on addressing
> misunderstanding like yours...
What misunderstanding? Either you are the one misunderstanding his
website, which seems quite likely, or his website isn't worth
visiting.
tho...@antispam.ham
That's Windows for you. I've loaded 45 minute recordings into my OS/2
audio editing software with no trouble. I do have the version of OS/2
that enables the use of high memory. My software actually checks for
the 512 MB per process limitation.
Ilya Zakharevich
[Omitting the stuff already satisfactory covered in my other posts]
>> Your input is
>> 96/24; internally, it is quite probable that your sound card's DAC
>> works ONLY in 96/24.
> On what do you base that claim? Why not 192 kHz?
May be, but does not matter. The assumption is that DAC works at a
FIXED rate.
>> In this case, you WILL downconvert to 48/16,
>
> Not if the sound card supports 96/24.
Irrelevant. You WILL since on OS/2 currently there is no other solution.
>> and the internal hardware WILL upconvert to 96/24 again.
> On what do you base that claim?
On the assumption above on how DAC works.
> Fortunately for you, because you can make all the claims you want to
> make with no easy way to prove that you're right or wrong.
One can prove things only if the other side listens. But feel free to
feel superior anyway...
> You were discussing multiple cases of what you consider to be overkill,
> like higher resolution (than the CD standard) reproduction methods,
> "audiophile" speaker cable, and even HDMI cable.
Correct - and "audiophile" stereo amplifiers as well. (And note that
this list does not involve mike cables and SP-DIF. ;-)
> Just because some
> people buy more expensive cable than they need doesn't automatically
> mean that higher resolution reproduction methods are similarly unneeded.
Feel free to clump them together on any criterion you like. (And if
you forgot: my reason to clump them together was the trustworthy
double-blind tests covered these particular pieces of equipment.)
>> [And what manufacturer of reproduction equipment are interested is
>> profit. If it sells, of course it makes a lot of sense to
>> manufacture it. Is it so hard to understand?]
>
> Once again, you're trying to make it sound like the only reason
> higher resolution reproduction methods exist is because some
> manufacturer is making money off of gullible consumers.
Looks like this.
>> A different question... [One I was answering was something like "Do I
>> think that everybody must agree with me blah blah blah" or somesuch.]
>
> You can't even remember the question, yet you claim it wasn't formulated
> well? Talk about baseless claims.
Well, I remember your questions quite well. Too bad that you can't
even RECOGNIZE your own question... Well, this is what your
newsreader is for - to remind you.
Hope this helps,
Ilya
Ilya Zakharevich
>> Interpolator == Low pass filter.
>
> I'm well aware that your equation is BS.
>
>> If you do not understand this,
>
> Suppose I want to UP convert from a lower sampling rate to a higher
> sampling rate. You still need an interpolator, but it's definitely
> not acting as a low pass filter.
Feel free to refuse to believe things which are above your head...
But I STRONGLY recommend you reading Mitchell papers - they are quite
accessible to general public.
Hope this helps,
Ilya
Lars Erdmann
Reality might be different. If some manufacturer develops an audio device
driver that is just a piece of sh... and the audio device driver does not
properly report back what it intends to do (using a predefined/fixed sample
rate when it reports back that it will use the requested one etc.) then no
proper design concept in the world can catch that.
OS/2 multimedia subsystem relies on audio device drivers to do the things
right.
Just like the GRADD subsystem relies on GRADD device drivers to do the
things right.
For the first case described below: I browsed some audio device driver
source from the DDK. An audio device driver can report back a "best match"
for a requested sampling rate. If that is then useful in practice, I doubt
it. I guess feeding a stream with a sampling rate that differs from the
sampling rate used for playback will lead to "chip munks" or "boogey man"
sound, won't it ? (Do all sound cards have an analogue low pass filter after
D/A conversion ? Then at least, the distortion is minimized on playback).
For the second case desribed below: a sampling rate and bits per sample are
defined per audio stream. If the sound HW supports simultaneous audio
streams, then an OS/2 audio device driver can happily support that. The
design concept of OS/2 multimedia subsystem supports that.
Lars
"Ilya Zakharevich" <nospam...@ilyaz.org> schrieb im Newsbeitrag
news:slrnhsqk74.rp...@powdermilk.math.berkeley.edu...
Lars Erdmann
> On 2010-04-20, tho...@antispam.ham <tho...@antispam.ham> wrote:
>
> [Omitting the stuff already satisfactory covered in my other posts]
>
>>> Your input is
>>> 96/24; internally, it is quite probable that your sound card's DAC
>>> works ONLY in 96/24.
>
>> On what do you base that claim? Why not 192 kHz?
>
> May be, but does not matter. The assumption is that DAC works at a
> FIXED rate.
How do you know that ? And are you talking about A/D conversion or about D/A
conversion ? I'd expect that if an audio driver reports that it can handle
different sampling rates that then it DOES sample at different sampling
rates (for recording) or plays back at different sampling rates (for
playback) in HW ! If not, you will need some SW to convert from the source
to the target sampling rate. Likewise for the resolution.
For the record: a long time ago,during summer time, I worked at a record
company that would record everything with 24 bits per sample.
They knew that CDs would only support 16 bits per sample. They did anyways
as they expected that in the future there would be systems that would
provide 24 bits of resolution.
Therefore, they had some software that would reduce the resolution from 24
bits to 16 bits before they would put it on CD.
THAT process can be complicated. If you just chop off the 8 least
significant bits the result might not be the best you can get.
Converting the sampling rate can even be more complicated if the source and
target sampling rate are not even multiples of each other.
And even if they are, if you upsample, it might NOT be the best solution to
just do a linear interpolation to compute the "missing samples" because in
frequency domain that translates into a low-pass filtering with a low-pass
filter that is not very "steep" (I seem to remember, in the frequency
domain, it will have a form of sin(f)/f). You want to use a more
sophisticated low-pass filter like a Tchebycheff filter that, in time
domain, translates into a convolution that does more than just do a linear
interpolation.
If the source and target sampling rates are not even multiples of each
other, the situation becomes even more complex.
I learned all this more than 20 years ago and never used it thereafter,
sorry for the blurriness of my memory ...
Lars
tho...@antispam.ham
> [Omitting the stuff already satisfactory covered in my other posts]
In your mind. In reality, you deleted the text where you claimed to
know what sampling rate and bit depth that I was going to use. I
pointed out that you were wrong about it, so it's no surprise that
you would want to eliminate that from your follow-up.
>>> Your input is
>>> 96/24; internally, it is quite probable that your sound card's DAC
>>> works ONLY in 96/24.
>> On what do you base that claim? Why not 192 kHz?
> May be, but does not matter. The assumption is that DAC works at a
> FIXED rate.
In other words, you don't know. You can only assume. How do you
suppose a digital audio recorder can offer sampling rates of both
96 kHz and 44.1 kHz? By really sampling at a much higher rate that
is an integer multiple of both 96000 and 44100 and then using only
every Nth sample? Or is it always sampling at its highest rate
and performing a sampling rate conversion in firmware?
>>> In this case, you WILL downconvert to 48/16,
>> Not if the sound card supports 96/24.
> Irrelevant.
On the contrary, it's quite relevant. Why waste CPU time doing a
conversion if it's unnecessary?
> You WILL since on OS/2 currently there is no other solution.
How do you know? My original question was if there is a way to
query a system about its capabilities. You still haven't offered
an answer to that question, but now you're saying that you somehow
know OS/2's capabilities.
>>> and the internal hardware WILL upconvert to 96/24 again.
>> On what do you base that claim?
> On the assumption above on how DAC works.
In other words, you don't know. You can only assume. Try answering
the question above about how digital recorders offer both 96 and 44.1
kHz sampling rates.
>> Fortunately for you, because you can make all the claims you want to
>> make with no easy way to prove that you're right or wrong.
> One can prove things only if the other side listens.
And so far you haven't been listening very well.
> But feel free to feel superior anyway...
How I feel is irrelevant. What is relevant is the fact that you still
haven't answered the original question. All you've done is to
hypocritically try to impose your own agenda.
>> You were discussing multiple cases of what you consider to be overkill,
>> like higher resolution (than the CD standard) reproduction methods,
>> "audiophile" speaker cable, and even HDMI cable.
> Correct - and "audiophile" stereo amplifiers as well. (And note that
> this list does not involve mike cables and SP-DIF. ;-)
The specifics are irrelevant; you were simply trying to use examples
where you felt that choice of cable didn't matter. How nice of you
to invalidate your own argument by now noting counter examples where
choice of cable can matter.
>> Just because some
>> people buy more expensive cable than they need doesn't automatically
>> mean that higher resolution reproduction methods are similarly unneeded.
> Feel free to clump them together on any criterion you like. (And if
> you forgot: my reason to clump them together was the trustworthy
> double-blind tests covered these particular pieces of equipment.)
And where are the alleged double-blind test results regarding 24-bit
96 kHz recordings?
>>> [And what manufacturer of reproduction equipment are interested is
>>> profit. If it sells, of course it makes a lot of sense to
>>> manufacture it. Is it so hard to understand?]
>> Once again, you're trying to make it sound like the only reason
>> higher resolution reproduction methods exist is because some
>> manufacturer is making money off of gullible consumers.
> Looks like this.
How it looks to you is irrelevant to me. You don't care about somebody
else's agenda, so why should I care about your agenda?
>>> A different question... [One I was answering was something like "Do I
>>> think that everybody must agree with me blah blah blah" or somesuch.]
>> You can't even remember the question, yet you claim it wasn't formulated
>> well? Talk about baseless claims.
> Well, I remember your questions quite well.
Then why say "something like" if you remember it so well?
> Too bad that you can't even RECOGNIZE your own question...
That doesn't even make sense. I'm the one who asked the question. It
up to the readers to comprehend the question and answer appropriately.
> Well, this is what your newsreader is for - to remind you.
That's not what my newsreader is for.
tho...@antispam.ham
>>> Interpolator == Low pass filter.
>> I'm well aware that your equation is BS.
>>> If you do not understand this,
>> Suppose I want to UP convert from a lower sampling rate to a higher
>> sampling rate. You still need an interpolator, but it's definitely
>> not acting as a low pass filter.
> Feel free to refuse to believe things which are above your head...
How ironic, considering the equality you presented previously.
> But I STRONGLY recommend you reading Mitchell papers - they are quite
> accessible to general public.
I strongly recommend that you think about the upconversion example
that I already provided. You do admit that to get 96 kHz from a
44.1 kHz original, you need to interpolate, right? Exactly which
high frequencies are getting filtered out by your so-called low-pass
filter in this case? Not that I expect you to answer the question,
given that the answer would be too damning.
Ilya Zakharevich
>> May be, but does not matter. The assumption is that DAC works at a
>> FIXED rate.
> How do you know that ? And are you talking about A/D conversion or about D/A
> conversion ?
"DAC" == D/A conversion
> I'd expect that if an audio driver reports that it can handle
> different sampling rates that then it DOES sample at different sampling
> rates (for recording) or plays back at different sampling rates (for
> playback) in HW !
1st: HW vs SW is fuzzy, is not it? I expect the OP won't care much
whether the conversion happens on CPU, or on on-card DSP chip.
2nd: if your expectations would hold, the card won't allow
simultaneous playback of different "formats". Many do.
> Therefore, they had some software that would reduce the resolution from 24
> bits to 16 bits before they would put it on CD.
> THAT process can be complicated. If you just chop off the 8 least
> significant bits the result might not be the best you can get.
Sure. See my original reply which contains the "best effort"
algorithm (with computational complexity of one addition per
sample-channel ;-).
But keep in mind that I'm not aware of any third-party double-blind
testing of whether the difference between "best you can get" and
"brain damaged bit chopping" is AUDIBLE.
> Converting the sampling rate can even be more complicated if the source and
> target sampling rate are not even multiples of each other.
THIS is irrelevant. AFAIK, what is important is the MAGNITUDE of the
ratio of frequencies - the larger, the easier to convert. (For small
differences, you need quite-high-order of low-pass filters...)
> And even if they are, if you upsample, it might NOT be the best solution to
> just do a linear interpolation to compute the "missing samples" because in
> frequency domain that translates into a low-pass filtering with a low-pass
> filter that is not very "steep" (I seem to remember, in the frequency
> domain, it will have a form of sin(f)/f).
This is one of 3 possible correct answers ;-); the other two are "the
square of this" [the most correct one ;-], and 1.
(The problem is how you represent the initial sampled signal: the
most correct representation is as "impulses" [= delta-functions] at
the "moments of sampling", with 0s in between; the next one is to
represent them as step-functions [= piecewise-constant functions];
the third is to represent them as piecewise-linear functions. The
next one differs from the previous one by sin(f)/f-filtering.)
> You want to use a more sophisticated low-pass filter like a
> Tchebycheff filter that, in time domain, translates into a
> convolution that does more than just do a linear interpolation.
IIRC, for CD production people were using about 20-tap (sp?) filtering
(but I read the corresponding technical papers about 20 years ago -
memory may be fuzzy). However, one should keep this in perspective:
2N-tap filtering is only 2x more expensive than N-tap filtering - and
with puny rate of samples coming, this is NOTHING comparing to the
power of today's processors.
Just to put it in relation of what kind of DSP is considered
"challenging" today, but is done on thousands of units: Mysterium-X
provides data at the rate of about 1G 16-bit-samples/sec (IIRC it is
15MPix x 60f/sec - but this is from memory of a year ago - I could not
find "after production started" tech sheets when I was looking a short
time ago).
> If the source and target sampling rates are not even multiples of each
> other, the situation becomes even more complex.
No, AFAIK, with proper filtering this is not relevant (due to equivalence
filtering == interpolation).
> I learned all this more than 20 years ago and never used it thereafter,
> sorry for the blurriness of my memory ...
20 years ago - same for me. But about 2 years ago I re-investigated
these matters (including psycho-acoustical component) due to
appearence of higher-resolution formats. (And due to importance of DSP
of visual imagery for my photographic side.)
Yours,
Ilya
Ilya Zakharevich
>> [Omitting the stuff already satisfactory covered in my other posts]
>
> In your mind. In reality, you deleted the text where you claimed to
> know what sampling rate and bit depth that I was going to use. I
> pointed out that you were wrong about it, so it's no surprise that
> you would want to eliminate that from your follow-up.
Looks like you persist in covering the same ground again and again.
OK, let me repeat it: I was not wrong about what you are going to do.
YOU JUST HAVE NO CHOICE. What is so hard to understand about it?
You may pepper your posts with "unacceptable" as much as you want.
Still, compared to "no technical possibility", this is quite a fragile
argument, is not it? :-(
[Of course, there is ONE way in which I may be proven wrong. If my
posts in this thread annoy somebody STRONG ENOUGH, they may sit
down and spend a weekend (?) to add 192/24-passthrough to UNIAUD
drivers. ;-)
And if I'm proven wrong in THIS way, all I'm going to be is very
glad (so if one IS annoyed enough to do the above, PLEASE do not
read this sentence ;-).
But my guess is that your strength is wishful thinking, not
technical expertise, so it is not going to be you? (Please prove
me wrong!) ]
>> You WILL since on OS/2 currently there is no other solution.
> How do you know?
Maybe because I investigated this question? Probably not - looks that
you think it is way above my head...
>> Feel free to clump them together on any criterion you like. (And if
>> you forgot: my reason to clump them together was the trustworthy
>> double-blind tests covered these particular pieces of equipment.)
> And where are the alleged double-blind test results regarding 24-bit
> 96 kHz recordings?
If you STARTED with this question, I would bother to try to locate
these studies again. Now, feel free to google yourself.
(But if somebody else is interested, contact me. I must have stored
it somewhere in my HOWTO/TODO folders - so I do not need to rely on
google.)
>> Too bad that you can't even RECOGNIZE your own question...
> That doesn't even make sense. I'm the one who asked the question.
And now you claim you did not. Just look back in the thread. On my
newsreader, it is as hard as pressing `Left' several times.
Hope this helps,
Ilya
Ilya Zakharevich
> Just to put it in relation of what kind of DSP is considered
> "challenging" today, but is done on thousands of units: Mysterium-X
Oups, somehow I was mentally challenged when I wrote this: the
"currently shipped thousands" of Mysterium-X's are lobotomized to work
with "old brains". So they must be ACTUALLY USED with much lower data
rates - probably within 20% of the rates of the "old" Mysterium... So
until "later in this year" ;-), the rate should be decreased by half
an order of magnitude.
Still 3 orders of magnitude higher than what we discuss here...
Ilya
tho...@antispam.ham
> Lars Erdmann <lars.e...@arcor.de> wrote:
>>> May be, but does not matter. The assumption is that DAC works at a
>>> FIXED rate.
>> How do you know that ? And are you talking about A/D conversion or about D/A
>> conversion ?
> "DAC" == D/A conversion
You didn't answer Lars' question about how you know that the DAC
works at a fixed rate. Of course, you don't know. That's why
you called it an assumption.
>> I'd expect that if an audio driver reports that it can handle
>> different sampling rates that then it DOES sample at different sampling
>> rates (for recording) or plays back at different sampling rates (for
>> playback) in HW !
> 1st: HW vs SW is fuzzy, is not it? I expect the OP won't care much
> whether the conversion happens on CPU, or on on-card DSP chip.
What you expect is irrelevant.
> 2nd: if your expectations would hold, the card won't allow
> simultaneous playback of different "formats". Many do.
And the only way that can be done is to use a single fixed rate?
>> Therefore, they had some software that would reduce the resolution from 24
>> bits to 16 bits before they would put it on CD.
>> THAT process can be complicated. If you just chop off the 8 least
>> significant bits the result might not be the best you can get.
> Sure. See my original reply which contains the "best effort"
> algorithm (with computational complexity of one addition per
> sample-channel ;-).
So you're contradicting yourself. First you agree with Lars that the
process can be complicated by saying "sure", and then you claim that
the computational complexity is just one addition per sample-channel.
At this point, it's worth noting that Audacity, for example, converts
everything to 32-bit floating point so that rounding error doesn't
occur on each and every editing operation when working in the integer
domain. It waits until the user tells it to convert back to integers.
Thus producing a 16-bit integer sample stream for the sound card to
play isn't as simple as chopping off the least significant bits.
> But keep in mind that I'm not aware of any third-party double-blind
> testing of whether the difference between "best you can get" and
> "brain damaged bit chopping" is AUDIBLE.
You keep talking about the audibility of conversions, but that has
never been the issue. The issue has been the CPU time needed to do
the conversion, and that conversion includes both the bit-depth change
and the sampling rate change. I want to avoid doing the conversion,
if possible, but I need to know the capabilities of the system before
deciding whether it's necessary to do the conversion or not.
>> Converting the sampling rate can even be more complicated if the source and
>> target sampling rate are not even multiples of each other.
> THIS is irrelevant.
On the contrary, it's very relevant, because it's the most time-consuming
portion of the conversion process. I want to avoid it, if possible.
> AFAIK, what is important is the MAGNITUDE of the
> ratio of frequencies - the larger, the easier to convert. (For small
> differences, you need quite-high-order of low-pass filters...)
And the direction doesn't matter? With down-conversion, you need to
remove the frequencies above the new Nyquist limit to avoid aliasing,
but with up-conversion, that isn't necessary.
>> And even if they are, if you upsample, it might NOT be the best solution to
>> just do a linear interpolation to compute the "missing samples" because in
>> frequency domain that translates into a low-pass filtering with a low-pass
>> filter that is not very "steep" (I seem to remember, in the frequency
>> domain, it will have a form of sin(f)/f).
> This is one of 3 possible correct answers ;-); the other two are "the
> square of this" [the most correct one ;-], and 1.
>
> (The problem is how you represent the initial sampled signal: the
> most correct representation is as "impulses" [= delta-functions] at
> the "moments of sampling", with 0s in between; the next one is to
> represent them as step-functions [= piecewise-constant functions];
> the third is to represent them as piecewise-linear functions. The
> next one differs from the previous one by sin(f)/f-filtering.)
Something is either correct or not. By saying "most correct", you're
implying that the other methods are "less correct", but isn't that the
same as saying "wrong"?
>> You want to use a more sophisticated low-pass filter like a
>> Tchebycheff filter that, in time domain, translates into a
>> convolution that does more than just do a linear interpolation.
> IIRC, for CD production people were using about 20-tap (sp?) filtering
> (but I read the corresponding technical papers about 20 years ago -
> memory may be fuzzy). However, one should keep this in perspective:
> 2N-tap filtering is only 2x more expensive than N-tap filtering - and
> with puny rate of samples coming, this is NOTHING comparing to the
> power of today's processors.
The only way that two times something can equal nothing is for the
something to be nothing. But isn't that contradictory?
> Just to put it in relation of what kind of DSP is considered
> "challenging" today, but is done on thousands of units: Mysterium-X
> provides data at the rate of about 1G 16-bit-samples/sec (IIRC it is
> 15MPix x 60f/sec - but this is from memory of a year ago - I could not
> find "after production started" tech sheets when I was looking a short
> time ago).
Gee, wouldn't it be nice if you could simply query the hardware as to
its capabilities. Then you'd have your answer. Gosh, that sounds an
awful lot like my initial question.
>> If the source and target sampling rates are not even multiples of each
>> other, the situation becomes even more complex.
> No, AFAIK, with proper filtering this is not relevant (due to equivalence
> filtering == interpolation).
So you've changed your tune again. Before, interpolation was equivalent
to low-pass filtering. Now it's just equivalent to filtering. That's
after I asked which high frequencies were filtered out during the
interpolation in an up-conversion.
>> I learned all this more than 20 years ago and never used it thereafter,
>> sorry for the blurriness of my memory ...
> 20 years ago - same for me. But about 2 years ago I re-investigated
> these matters (including psycho-acoustical component) due to
> appearence of higher-resolution formats. (And due to importance of DSP
> of visual imagery for my photographic side.)
>
> Yours,
Interesting that you didn't wonder whether it helped him.
tho...@antispam.ham
>>> [Omitting the stuff already satisfactory covered in my other posts]
>> In your mind. In reality, you deleted the text where you claimed to
>> know what sampling rate and bit depth that I was going to use. I
>> pointed out that you were wrong about it, so it's no surprise that
>> you would want to eliminate that from your follow-up.
> Looks like you persist in covering the same ground again and again.
Only because you keep claiming that I don't understand the situation,
thus it's necessary to cover the same ground until you understand that
I understand the situation.
> OK, let me repeat it: I was not wrong about what you are going to do.
Yes, you are wrong. Or are you claiming that you can read my mind?
> YOU JUST HAVE NO CHOICE.
That's not true either. I could, for example, record at 96 kHz and
convert to 48 kHz, which avoids the need to interpolate. My system
can handle 48 kHz, which I determined by direct experimentation
rather than some software query. Another choice is to record at
96 kHz and convert to 44.1 kHz, but that requires interpolation.
> What is so hard to understand about it?
Understanding that you're wrong isn't hard at all. What's hard is
trying to get you to realize that you're wrong.
> You may pepper your posts with "unacceptable" as much as you want.
That's rather ironic, coming from someone who keeps peppering his
posts with the equivalent of "acceptable" because it's inaudible.
But the audibility is not and has never been the issue.
> Still, compared to "no technical possibility", this is quite a fragile
> argument, is not it? :-(
Your argument has indeed been quite fragile. So why do you persist?
> [Of course, there is ONE way in which I may be proven wrong. If my
> posts in this thread annoy somebody STRONG ENOUGH, they may sit
> down and spend a weekend (?) to add 192/24-passthrough to UNIAUD
> drivers. ;-)
You think that's the only way you can be proven wrong?
> And if I'm proven wrong in THIS way, all I'm going to be is very
> glad (so if one IS annoyed enough to do the above, PLEASE do not
> read this sentence ;-).
Why would you be glad over being proven wrong?
> But my guess is that your strength is wishful thinking, not
> technical expertise, so it is not going to be you? (Please prove
> me wrong!) ]
I already have proven you wrong. See above where you claim that I have
no choice.
>>> You WILL since on OS/2 currently there is no other solution.
>> How do you know?
> Maybe because I investigated this question?
Aren't you sure?
> Probably not - looks that you think it is way above my head...
What I think is irrelevant. What is relevant is that you never
answered my question about whether it's possible to query the
audio capabilities of a system. Why you didn't answer the question
is a matter of speculation. Perhaps it's because it's way above
your head.
>>> Feel free to clump them together on any criterion you like. (And if
>>> you forgot: my reason to clump them together was the trustworthy
>>> double-blind tests covered these particular pieces of equipment.)
>> And where are the alleged double-blind test results regarding 24-bit
>> 96 kHz recordings?
> If you STARTED with this question, I would bother to try to locate
> these studies again. Now, feel free to google yourself.
What difference does it make whether the question is asked first or
later? You made the claim about the double-blind tests, but you have
yet to offer any evidence to support the claim.
> (But if somebody else is interested, contact me. I must have stored
> it somewhere in my HOWTO/TODO folders - so I do not need to rely on
> google.)
Ah, the old "I have it here somewhere" response.
>>> Too bad that you can't even RECOGNIZE your own question...
>> That doesn't even make sense. I'm the one who asked the question.
> And now you claim you did not.
Where did I claim that I didn't ask the question?
> Just look back in the thread.
Where?
> On my newsreader, it is as hard as pressing `Left' several times.
Pressing "left" on your newsreader causes it to make up imaginary
claims? That explains a lot.
> Hope this helps,
Not a "Yours"?
Marty
> Ilya Zakharevich <nospam...@ilyaz.org> writes:
>
>> You may pepper your posts with "unacceptable" as much as you want.
>
> That's rather ironic, coming from someone who keeps peppering his
> posts with the equivalent of "acceptable" because it's inaudible.
> But the audibility is not and has never been the issue.
This is one thing that baffles me a bit about Ilya's postings here. You
asked a very specific how-to oriented question in a newsgroup dedicated
to exploring such topics as "what is possible in OS/2 multimedia?".
Ilya's argument tends to boil down to "You shouldn't be doing that
because I don't think it's necessary." Even if we bury our heads and
believe him that it isn't necessary or useful, it's still an appropriate
question in this newsgroup which deserves a real answer (thanks Lars!).
We want to discuss methods of accessing OS/2 multimedia and the extent
of its capabilities here. One or two posts of "I don't believe that
this capability is useful/necessary", ok. But this is turning into a
veritable crusade. A bit puzzling to me...
--
[Reverse the parts of the e-mail address to reply.]
Ilya Zakharevich
> Ilya's argument tends to boil down to "You shouldn't be doing that
> because I don't think it's necessary."
No. My argument is "You do not NEED to query the system since you
already know the answer" and "you should downconvert since you have no
choice - but it won't hurt your listening experience".
Hope this helps,
Ilya
Ilya Zakharevich
>
> That's not true either. I could, for example, record at 96 kHz and
> convert to 48 kHz
This is exactly what I suggested. You need to convert to the best
format which the driver understands.
> Where did I claim that I didn't ask the question?
Use your newsreader and inspect the thread.
Hope this helps,
Ilya
Ilya Zakharevich
>>> different sampling rates that then it DOES sample at different sampling
>>> rates (for recording) or plays back at different sampling rates (for
>>> playback) in HW !
>
>> 1st: HW vs SW is fuzzy, is not it? I expect the OP won't care much
>> whether the conversion happens on CPU, or on on-card DSP chip.
>> simultaneous playback of different "formats". Many do.
>
> And the only way that can be done is to use a single fixed rate?
*Theoretically*, one could use many DACs and add the output by
analogue circuits. Do you know any such card?
>>> Therefore, they had some software that would reduce the resolution from 24
>>> bits to 16 bits before they would put it on CD.
>>> THAT process can be complicated. If you just chop off the 8 least
>>> significant bits the result might not be the best you can get.
>
>> Sure. See my original reply which contains the "best effort"
>> algorithm (with computational complexity of one addition per
>> sample-channel ;-).
>
> So you're contradicting yourself. First you agree with Lars that the
> process can be complicated by saying "sure", and then you claim that
> the computational complexity is just one addition per sample-channel.
"Sure" was confirming the preceeding sentence. Is it so hard to understand?
> At this point, it's worth noting that Audacity, for example, converts
> everything to 32-bit floating point so that rounding error doesn't
> occur on each and every editing operation when working in the integer
> domain.
The situation is exactly the opposite: to avoid rounding errors,
people do calculations in integer domain, not in floating point
domain. The major thing 32-bit FP is better than 24bit integers is
handling overflow (assuming 24-bit sign+mantissa - do not remember how
32bit IEEE FP works - but Audacity might have invented its own format
of FP...).
> You keep talking about the audibility of conversions, but that has
> never been the issue. The issue has been the CPU time needed to do
> the conversion
*This* is going to be negligible.
>> AFAIK, what is important is the MAGNITUDE of the
>> ratio of frequencies - the larger, the easier to convert. (For small
>> differences, you need quite-high-order of low-pass filters...)
>
> And the direction doesn't matter? With down-conversion, you need to
> remove the frequencies above the new Nyquist limit to avoid aliasing,
> but with up-conversion, that isn't necessary.
Wrong. Also necessary. This is called interpolation, which is
equivalent to filtering.
>> This is one of 3 possible correct answers ;-); the other two are "the
>> square of this" [the most correct one ;-], and 1.
>>
>> (The problem is how you represent the initial sampled signal: the
>> most correct representation is as "impulses" [= delta-functions] at
>> the "moments of sampling", with 0s in between; the next one is to
>> represent them as step-functions [= piecewise-constant functions];
>> the third is to represent them as piecewise-linear functions. The
>> next one differs from the previous one by sin(f)/f-filtering.)
>
> Something is either correct or not. By saying "most correct", you're
> implying that the other methods are "less correct", but isn't that the
> same as saying "wrong"?
No.
All three methods are equivalent. They are "just ways of
visualization of what sampled signal represents"; they differ only by
filtering (=interpolation). So all the difference may be subsumed in
the follow-up filtering.
>>> You want to use a more sophisticated low-pass filter like a
>>> Tchebycheff filter that, in time domain, translates into a
>>> convolution that does more than just do a linear interpolation.
>
>> IIRC, for CD production people were using about 20-tap (sp?) filtering
>> (but I read the corresponding technical papers about 20 years ago -
>> memory may be fuzzy). However, one should keep this in perspective:
>> 2N-tap filtering is only 2x more expensive than N-tap filtering - and
>> with puny rate of samples coming, this is NOTHING comparing to the
>> power of today's processors.
>
> The only way that two times something can equal nothing is for the
> something to be nothing. But isn't that contradictory?
No. Both methods would require negligible percentage of CPU.
>> Just to put it in relation of what kind of DSP is considered
>> "challenging" today, but is done on thousands of units: Mysterium-X
>> provides data at the rate of about 1G 16-bit-samples/sec (IIRC it is
>> 15MPix x 60f/sec - but this is from memory of a year ago - I could not
>> find "after production started" tech sheets when I was looking a short
>> time ago).
>
> Gee, wouldn't it be nice if you could simply query the hardware as to
> its capabilities.
Well, first of all, I'm quite interesting in video production (as far
as it is not low resolution video, like 1280x720, - to shoot THAT one
would need good actors - and directors ;-). Still, not interested
enough to chip $25000 and query the hardware directly. ;-)
> Then you'd have your answer. Gosh, that sounds an
> awful lot like my initial question.
Yours,
Ilya
tho...@antispam.ham
> Marty <n...@comcast.martyamodeo> wrote:
>> Ilya's argument tends to boil down to "You shouldn't be doing that
>> because I don't think it's necessary."
> No.
Actually, Marty's statememt is a rather accurate summary of your
position.
> My argument is "You do not NEED to query the system since you
> already know the answer" and "you should downconvert since you have no
> choice - but it won't hurt your listening experience".
How do you know there's no choice? You're familiar with the capabilities
of absolutely every sound card with an OS/2 driver?
But the issue has never been audibility. Rather, the issue has been
the CPU time needed to do the conversion every time I want to listen
to a segment to hear the effect of an edit, and my practical
experience has shown that the time isn't negligible. Your Mysterium
example is irrelevant because I don't have a Mysterium in my system.
I'm working with what I have, which is an Analog Devices chipset
built into an Intel motherboard from seven years ago.
> Hope this helps,
Baseless hope.
tho...@antispam.ham
>>> YOU JUST HAVE NO CHOICE.
>> That's not true either. I could, for example, record at 96 kHz and
>> convert to 48 kHz
> This is exactly what I suggested.
No, it's not. You suggested converting to 44.1 kHz because you know
that the CD standard is supported.
> You need to convert to the best
> format which the driver understands.
But that brings us back to the original question: what is the best
format that the driver understands? Is there a way to query the
system to find out? You just finished claiming in your response to
Marty that you don't need to query the system because you already
know the answer, but I don't know the answer. If I hadn't tried
the 48 kHz option on my system, I could have only assumed that
44.1 kHz is the best format that the driver understands. But how
would YOU have determined that my system supports 48 kHz?
>> Where did I claim that I didn't ask the question?
> Use your newsreader and inspect the thread.
You made the claim, therefore you should be the one doing the
legwork to support your claim.
tho...@antispam.ham
>>>> I'd expect that if an audio driver reports that it can handle
>>>> different sampling rates that then it DOES sample at different sampling
>>>> rates (for recording) or plays back at different sampling rates (for
>>>> playback) in HW !
>>> 1st: HW vs SW is fuzzy, is not it? I expect the OP won't care much
>>> whether the conversion happens on CPU, or on on-card DSP chip.
>>> 2nd: if your expectations would hold, the card won't allow
>>> simultaneous playback of different "formats". Many do.
>> And the only way that can be done is to use a single fixed rate?
> *Theoretically*, one could use many DACs and add the output by
> analogue circuits. Do you know any such card?
I know that my sound system supports the simultaneous playing of a
source from a microphone, a source from a line input, a source from
a CD, and a source from a WAV file, but it does NOT support the
simultaneous playing of two WAV files. I'll let you put two and two
together.
>>>> Therefore, they had some software that would reduce the resolution from 24
>>>> bits to 16 bits before they would put it on CD.
>>>> THAT process can be complicated. If you just chop off the 8 least
>>>> significant bits the result might not be the best you can get.
>>> Sure. See my original reply which contains the "best effort"
>>> algorithm (with computational complexity of one addition per
>>> sample-channel ;-).
>> So you're contradicting yourself. First you agree with Lars that the
>> process can be complicated by saying "sure", and then you claim that
>> the computational complexity is just one addition per sample-channel.
> "Sure" was confirming the preceeding sentence. Is it so hard to understand?
Not at all, which is why I said you AGREED with Lars, or to use your
terminology, you confirmed the preceeding [sic] sentence. But then
you turned around and said it wasn't complex at all, because it's
just one addition per sample-channel. That's a contradiction.
>> At this point, it's worth noting that Audacity, for example, converts
>> everything to 32-bit floating point so that rounding error doesn't
>> occur on each and every editing operation when working in the integer
>> domain.
> The situation is exactly the opposite: to avoid rounding errors,
> people do calculations in integer domain, not in floating point
> domain.
Huh? Are you trying to tell me that if I want to reduce the gain by
a factor of 3, but I have a 16-bit integer sample value of 100, which
becomes a 33 after an integer division by 3 and rounding down to the
nearest integer, that that result has less rounding error than a 32-bit
real number being divided by 3 to produce a 33.33333 result?
> The major thing 32-bit FP is better than 24bit integers is
> handling overflow (assuming 24-bit sign+mantissa - do not remember how
> 32bit IEEE FP works - but Audacity might have invented its own format
> of FP...).
Although 32-bit floating point offers greater dynamic range, I'd
hardly call it the major advantage, because if your destination is a
CD, then you'll not be able to take advantage of the dynamic range in
the end. But you can avoid rounding every time you perform an
operation that changes an integer value.
>> You keep talking about the audibility of conversions, but that has
>> never been the issue. The issue has been the CPU time needed to do
>> the conversion
> *This* is going to be negligible.
Prove it. Don't try to invoke the speed of the Mysterium. I don't
have one, and you've already demonstrated that your memory about
the capabilities of the Mysterium isn't all that good.
>>> AFAIK, what is important is the MAGNITUDE of the
>>> ratio of frequencies - the larger, the easier to convert. (For small
>>> differences, you need quite-high-order of low-pass filters...)
>> And the direction doesn't matter? With down-conversion, you need to
>> remove the frequencies above the new Nyquist limit to avoid aliasing,
>> but with up-conversion, that isn't necessary.
> Wrong.
Oh? Tell me, what frequencies are above the 96 kHz Nyquist limit in
a recording that was originally made at 44.1 kHz?
> Also necessary.
Prove it.
> This is called interpolation, which is equivalent to filtering.
According to you, it's equivalent to low-pass filtering. Or have you
finally changed your tune on that?
>>> This is one of 3 possible correct answers ;-); the other two are "the
>>> square of this" [the most correct one ;-], and 1.
>>>
>>> (The problem is how you represent the initial sampled signal: the
>>> most correct representation is as "impulses" [= delta-functions] at
>>> the "moments of sampling", with 0s in between; the next one is to
>>> represent them as step-functions [= piecewise-constant functions];
>>> the third is to represent them as piecewise-linear functions. The
>>> next one differs from the previous one by sin(f)/f-filtering.)
>> Something is either correct or not. By saying "most correct", you're
>> implying that the other methods are "less correct", but isn't that the
>> same as saying "wrong"?
> No.
Then how is it "less correct" while still being correct?
> All three methods are equivalent.
Yet another contradiction. They can't be equivalent if one is more
correct than the others.
> They are "just ways of
> visualization of what sampled signal represents"; they differ only by
> filtering (=interpolation). So all the difference may be subsumed in
> the follow-up filtering.
How does that make one method "more correct" than the others?
>>>> You want to use a more sophisticated low-pass filter like a
>>>> Tchebycheff filter that, in time domain, translates into a
>>>> convolution that does more than just do a linear interpolation.
>>> IIRC, for CD production people were using about 20-tap (sp?) filtering
>>> (but I read the corresponding technical papers about 20 years ago -
>>> memory may be fuzzy). However, one should keep this in perspective:
>>> 2N-tap filtering is only 2x more expensive than N-tap filtering - and
>>> with puny rate of samples coming, this is NOTHING comparing to the
>>> power of today's processors.
>> The only way that two times something can equal nothing is for the
>> something to be nothing. But isn't that contradictory?
> No. Both methods would require negligible percentage of CPU.
There is a difference between negligible and nothing.
>>> Just to put it in relation of what kind of DSP is considered
>>> "challenging" today, but is done on thousands of units: Mysterium-X
>>> provides data at the rate of about 1G 16-bit-samples/sec (IIRC it is
>>> 15MPix x 60f/sec - but this is from memory of a year ago - I could not
>>> find "after production started" tech sheets when I was looking a short
>>> time ago).
>> Gee, wouldn't it be nice if you could simply query the hardware as to
>> its capabilities.
> Well, first of all, I'm quite interesting in video production (as far
> as it is not low resolution video, like 1280x720, - to shoot THAT one
> would need good actors - and directors ;-). Still, not interested
> enough to chip $25000 and query the hardware directly. ;-)
That doesn't even make sense.
>> Then you'd have your answer. Gosh, that sounds an
Ilya Zakharevich
>> My argument is "You do not NEED to query the system since you
>> already know the answer" and "you should downconvert since you have no
>> choice - but it won't hurt your listening experience".
> How do you know there's no choice? You're familiar with the capabilities
> of absolutely every sound card with an OS/2 driver?
Do you actually think there are many? Anyway, I'm familiar with what
people who actually know this staff say. Quite enough for me.
(I'm just delegating responsibilities. ;-)
> But the issue has never been audibility. Rather, the issue has been
> the CPU time needed to do the conversion every time I want to listen
> to a segment to hear the effect of an edit, and my practical
> experience has shown that the time isn't negligible.
Then show us what you consider to be your experience.
Yours,
Ilya
Ilya Zakharevich
> But that brings us back to the original question: what is the best
> format that the driver understands?
You already know it: you say it supports 44.1/16 and 48/16. This is
as far as it goes on OS/2.
Yours,
Ilya
Ilya Zakharevich
> Not at all, which is why I said you AGREED with Lars, or to use your
> terminology, you confirmed the preceeding [sic] sentence. But then
> you turned around and said it wasn't complex at all, because it's
> just one addition per sample-channel. That's a contradiction.
It would be no "contradiction" if you actually would spend some time
and read the "preceeding" (sic) sentence.
> Huh? Are you trying to tell me that if I want to reduce the gain by
> a factor of 3, but I have a 16-bit integer sample value of 100, which
> becomes a 33 after an integer division by 3 and rounding down to the
> nearest integer, that that result has less rounding error than a 32-bit
> real number being divided by 3 to produce a 33.33333 result?
I'm trying to tell you that your experience with quirks of FP
arithmetic is lacking. And integer arithmetic has no quirks.
>> The major thing 32-bit FP is better than 24bit integers is
>> handling overflow (assuming 24-bit sign+mantissa - do not remember how
>> 32bit IEEE FP works - but Audacity might have invented its own format
>> of FP...).
>
> Although 32-bit floating point offers greater dynamic range, I'd
> hardly call it the major advantage, because if your destination is a
> CD, then you'll not be able to take advantage of the dynamic range in
> the end.
Still, if some *intermediate results* overflow, you do not get
catastrophic loss of precision in the FINAL results.
> But you can avoid rounding every time you perform an
> operation that changes an integer value.
No, you cannot. FP operations round as often as integer ones. More
so if the mantissa bitwidth is lower (as in 32-bit integers vs 32-bit FP).
>>> And the direction doesn't matter? With down-conversion, you need to
>>> remove the frequencies above the new Nyquist limit to avoid aliasing,
>>> but with up-conversion, that isn't necessary.
>
>> Wrong.
>
> Oh? Tell me, what frequencies are above the 96 kHz Nyquist limit in
> a recording that was originally made at 44.1 kHz?
Easy: all of them. Any frequency f in the sampled recording is going to be
aliased to ALL the frequencies f + 2kN, with integer k, and N being
the Nyquist.
>> This is called interpolation, which is equivalent to filtering.
> According to you, it's equivalent to low-pass filtering.
Can you see the contradiction here as well? Good luck with your eye doctor...
> Then how is it "less correct" while still being correct?
I did refer you to Mitchell papers, did not I? How is your luck with them?
Yours,
Ilya
tho...@antispam.ham
>>> My argument is "You do not NEED to query the system since you
>>> already know the answer" and "you should downconvert since you have no
>>> choice - but it won't hurt your listening experience".
>> How do you know there's no choice? You're familiar with the capabilities
>> of absolutely every sound card with an OS/2 driver?
> Do you actually think there are many?
What I think is irrelevant. What I know is that you didn't answer
the question. But let's try this: why not you tell me the capabilities
of my sound card. Analog Devices.
> Anyway, I'm familiar with what
> people who actually know this staff say. Quite enough for me.
> (I'm just delegating responsibilities. ;-)
How convenient. So if you're wrong, you can simply blame somebody
else.
>> But the issue has never been audibility. Rather, the issue has been
>> the CPU time needed to do the conversion every time I want to listen
>> to a segment to hear the effect of an edit, and my practical
>> experience has shown that the time isn't negligible.
> Then show us what you consider to be your experience.
I just finished telling you that it's not negligble. Audacity supports
that position by offering "fast" and "good" options. Obviously, if
"good" involved a negligible amount of CPU time, it would also be fast,
and therefore the "fast" choice would be unnecessary.
tho...@antispam.ham
>>> You need to convert to the best format which the driver understands.
>> But that brings us back to the original question: what is the best
>> format that the driver understands?
> You already know it: you say it supports 44.1/16 and 48/16.
English isn't your strong suit, is it? I said "best". There can be
only one "best". You listed two, and it's entirely possible that
something better is available, in which case neither one would be
"best". But according to you, 44.1 kHz is already "good enough",
yet you've once again changed your tune by saying that one should
convert to the best format the driver understands. Suppose the
driver understands 96 kHz?
> This is as far as it goes on OS/2.
On what do you base that claim? You're absolutely positive that OS/2
doesn't support anything better than 48 kHz?
Ilya Zakharevich
>>> the CPU time needed to do the conversion every time I want to listen
>>> to a segment to hear the effect of an edit, and my practical
>>> experience has shown that the time isn't negligible.
>
>> Then show us what you consider to be your experience.
>
> I just finished telling you that it's not negligble. Audacity supports
> that position by offering "fast" and "good" options. Obviously, if
> "good" involved a negligible amount of CPU time, it would also be fast,
> and therefore the "fast" choice would be unnecessary.
Stop the BS; provide NUMBERS! E.g., how many CPU cycles used to
convert a 10sec sample.
Yours,
Ilya
tho...@antispam.ham
>>>> the CPU time needed to do the conversion every time I want to listen
>>>> to a segment to hear the effect of an edit, and my practical
>>>> experience has shown that the time isn't negligible.
>>> Then show us what you consider to be your experience.
>> I just finished telling you that it's not negligble. Audacity supports
>> that position by offering "fast" and "good" options. Obviously, if
>> "good" involved a negligible amount of CPU time, it would also be fast,
>> and therefore the "fast" choice would be unnecessary.
> Stop the BS; provide NUMBERS!
> E.g., how many CPU cycles used to convert a 10sec sample.
What alleged BS? I could just as easily tell you to stop the BS,
like your claim that interpolation is the same as low-pass filtering,
or like your claim that integer arithmetic has no quirks.
tho...@ifa.hawaii.edu
>>> "Sure" was confirming the preceeding sentence. Is it so hard to understand?
>> Not at all, which is why I said you AGREED with Lars, or to use your
>> terminology, you confirmed the preceeding [sic] sentence. But then
>> you turned around and said it wasn't complex at all, because it's
>> just one addition per sample-channel. That's a contradiction.
> It would be no "contradiction" if you actually would spend some time
> and read the "preceeding" (sic) sentence.
Like where Lars said THAT process can be complicated?
>> Huh? Are you trying to tell me that if I want to reduce the gain by
>> a factor of 3, but I have a 16-bit integer sample value of 100, which
>> becomes a 33 after an integer division by 3 and rounding down to the
>> nearest integer, that that result has less rounding error than a 32-bit
>> real number being divided by 3 to produce a 33.33333 result?
> I'm trying to tell you that your experience with quirks of FP
> arithmetic is lacking.
What do you know about my experience with FP?
> And integer arithmetic has no quirks.
Oh really? You think that 3/2 = 1 doesn't involve a quirk?
>>> The major thing 32-bit FP is better than 24bit integers is
>>> handling overflow (assuming 24-bit sign+mantissa - do not remember how
>>> 32bit IEEE FP works - but Audacity might have invented its own format
>>> of FP...).
>> Although 32-bit floating point offers greater dynamic range, I'd
>> hardly call it the major advantage, because if your destination is a
>> CD, then you'll not be able to take advantage of the dynamic range in
>> the end.
> Still, if some *intermediate results* overflow, you do not get
> catastrophic loss of precision in the FINAL results.
One major reason for using 24-bit during the recording process is
that you don't have to push either the upper or lower limits. If
you're pushing the 24-bit levels so close to 0 dBFS that you have
to worry about overflow with some intermediate result, then you're
not using the dynamic range properly.
>> But you can avoid rounding every time you perform an
>> operation that changes an integer value.
> No, you cannot.
> FP operations round as often as integer ones.
But they don't accumulate as fast because the amount of rounding
is a couple orders of magnitude smaller for 32-bit floating point
than for integer rounding when you're dealing with 16-bit integers.
> More so if the mantissa bitwidth is lower (as in 32-bit integers
> vs 32-bit FP).
I don't have a digital recorder that takes 32-bit integer samples.
>>>> And the direction doesn't matter? With down-conversion, you need to
>>>> remove the frequencies above the new Nyquist limit to avoid aliasing,
>>>> but with up-conversion, that isn't necessary.
>>> Wrong.
>> Oh? Tell me, what frequencies are above the 96 kHz Nyquist limit in
>> a recording that was originally made at 44.1 kHz?
> Easy: all of them.
Oh really? Tell me, how can a 44.1 kHz recording contain a 45 kHz
frequency?
> Any frequency f in the sampled recording is going to be
> aliased to ALL the frequencies f + 2kN, with integer k, and N being
> the Nyquist.
English really isn't your strong suit, is it? I said "in a
recording".
I did not say "in the original analog signal". A properly designed
digital recorder will remove frequencies above the Nyquist limit to
avoid the aliasing problem, therefore 45 kHz isn't going to be in a
44.1 kHz recording.
>>> This is called interpolation, which is equivalent to filtering.
>> According to you, it's equivalent to low-pass filtering.
> Can you see the contradiction here as well?
I call it inconsistency. First you called interpolation equivalent
to low-pass filtering, but after I pointed out the problem with your
claim, you switched to calling interpolation equivalent to filtering.
> Good luck with your eye doctor...
What do you think my eye doctor knows about digital signal processing?
>> Then how is it "less correct" while still being correct?
> I did refer you to Mitchell papers, did not I?
Once again, you didn't answer the question. The question was asked of
you, not of Mitchell. Mitchell hasn't posted in this newsgroup making
outrageous claims. You have.
> How is your luck with them?
Yet again, you didn't answer the question. It's so easy to conclude
that you don't have an answer.
Ilya Zakharevich
>> 96 kHz recordings?
>
> If you STARTED with this question, I would bother to try to locate
> these studies again. Now, feel free to google yourself.
Just stumbled on some link in my lynx's bookmark file today:
77. Audibility of a CD-Standard A/DA/A Loop Inserted into
High-Resolution Audio Playback by Meyer, E. Brad; Moran, David R.
http://www.aes.org/e-lib/browse.cfm?elib=14195
Probably I meant this link. Have no time to investigate now.
Ilya
tho...@antispam.ham
>>> And where are the alleged double-blind test results regarding 24-bit
>>> 96 kHz recordings?
>> If you STARTED with this question, I would bother to try to locate
>> these studies again. Now, feel free to google yourself.
> Just stumbled on some link in my lynx's bookmark file today:
It's been so long, you've apparently forgotten what the issue is,
even though the subject line serves as a reminder. I want to know
how to query the audio capabilities of my system. I don't care
whether you or some others think that a higher resolution format
is audibly different or not. Your reference only demonstrates
what is already known, namely that a difference is audible in
some circumstances and not audible in other circumstances. You've
already acknowledged the advantage of the higher resolution format
for recording. Given a higher resolution recording, I want to be
able to edit it without being forced to resample and reduce bit
depth every time that I want to listen to a segment to hear the
effect of an edit, if possible. You maintain that the cost in
CPU cycles is negligible, and I maintain that it is not.
I'm still waiting for an answer to the question "You're absolutely
positive that OS/2 doesn't support anything better than 48 kHz?"
> Probably I meant this link. Have no time to investigate now.
Probably?
Ilya Zakharevich
> is audibly different or not. Your reference only demonstrates
> what is already known, namely that a difference is audible in
> some circumstances and not audible in other circumstances.
No, AFAIK it says that the difference is not audible. (One can hear
the noise floor [but keep in mind that the workflow involved no noise
coloring!] if one plays silence AND raises loudness 14db above the
"normal listening level" [read: above the pain level for the loudest
possible segments]. Call this "audible in some circumstances" if you
want.)
> You've already acknowledged the advantage of the higher resolution
> format for recording.
This part is correct.
> Given a higher resolution recording, I want to be able to edit it
> without being forced to resample
This one is also reasonable.
> and reduce bit depth every time that I want to listen to a segment
> to hear the effect of an edit
This makes no sense, given the capabilities of the human hearing.
> You maintain that the cost in CPU cycles is negligible
Correct (although I never checked it). I think 100MCycles/sec is a
*very* pessimistic estimate.
> I'm still waiting for an answer to the question "You're absolutely
> positive that OS/2 doesn't support anything better than 48 kHz?"
I gave the answer many times.
Yours,
Ilya
James J. Weinkam
>
> I'm still waiting for an answer to the question "You're absolutely
> positive that OS/2 doesn't support anything better than 48 kHz?"
>
eCS2.0GA system running on a T60 using uniaud.
tho...@antispam.ham
>> is audibly different or not. Your reference only demonstrates
>> what is already known, namely that a difference is audible in
>> some circumstances and not audible in other circumstances.
> No, AFAIK it says that the difference is not audible.
Try reading it rather than relying on your memory.
> (One can hear
> the noise floor [but keep in mind that the workflow involved no noise
> coloring!] if one plays silence AND raises loudness 14db above the
> "normal listening level" [read: above the pain level for the loudest
> possible segments]. Call this "audible in some circumstances" if you
> want.)
What I want in this case is irrelevant. The difference is audible
in some circumstances.
>> You've already acknowledged the advantage of the higher resolution
>> format for recording.
> This part is correct.
Glad you agree.
>> Given a higher resolution recording, I want to be able to edit it
>> without being forced to resample
> This one is also reasonable.
Changing your position on this one, eh Ilya?
>> and reduce bit depth every time that I want to listen to a segment
>> to hear the effect of an edit
> This makes no sense, given the capabilities of the human hearing.
It has nothing to do with human hearing, Ilya. It has everything
to do with CPU cycles.
>> You maintain that the cost in CPU cycles is negligible
> Correct (although I never checked it). I think 100MCycles/sec is a
> *very* pessimistic estimate.
That's a useless number. As I pointed out before, there's more than
one way to change sampling rates. Audacity, for example, has its
fast way and its good way, and one can program a conversion process
between those two, thus the amount of time the process takes is
variable. The less time you spend on the conversion, the more likely
the conversion will introduce audible artifacts.
>> I'm still waiting for an answer to the question "You're absolutely
>> positive that OS/2 doesn't support anything better than 48 kHz?"
> I gave the answer many times.
No, you haven't.
tho...@antispam.ham
That's interesting. Do you know if all T60s use the same audio
hardware? The only systems I've run my editing software on are
a T23, a T42p, and a couple of older desktop systems with Intel
motherboards that have audio on board. My home desktop uses
Analog Devices hardware. I haven't found any sampling rate
above 65536 Hz that sounds right, though there is probably one
somewhere that will alias to the right frequency.
I've also discovered that eCS 2.0 GA on the T42p doesn't have
working audio in a WinOS2 session. I'm pretty sure it did
work in WinOS2 sessions when I had Warp 4.52 on the machine
some years ago, using the audio driver from the IBM device
driver matrix web pages.
James J. Weinkam
mplayer version. I just installed the latest mplayer, SVN-r30994-OS2-4.4.2. On my desktop,
everything works just as with the previous version, SVN-r27724-OS2-4.3.2. On the laptop, however,
the playback of 48 and 96KHz files is "choppy" in the new version. (I have reported this problem to
KO Myung-Hun). After some messing around I found that adding the line ao=kai:dart to the config file
fixed the problem.
Also, in the WPS, if you right click on a wav file and select Open as and then Player, 16 bit wav
files of any standard frequency up to 96KHz will play.
Steve Wendt
> Actually, I just discovered that results with mplayer may vary depending
> on sound card, driver, and mplayer version. I just installed the latest
> mplayer, SVN-r30994-OS2-4.4.2. On my desktop, everything works just as
> with the previous version, SVN-r27724-OS2-4.3.2. On the laptop, however,
> the playback of 48 and 96KHz files is "choppy" in the new version. (I
> have reported this problem to KO Myung-Hun). After some messing around I
> found that adding the line ao=kai:dart to the config file fixed the
> problem.
Playing via the KAI UniAud32 interface doesn't work for a lot of us. I
suppose it must work on some audio chipsets, but I've heard there are
plenty of people who get no sound output at all (including mine).
Heikki Kekki
wrote:
Works here with Sound Blaster 16
Description Sound Blaster 16 Device Driver
Vendor Creative Technology
Version 1.1 02.09.1994
--
Hessu
James J. Weinkam
I have usually found that the solution to no sound at all is to fire up a mixer application such as
LBMix that can unmute or raise the level of the wave input. I have never been able to get unimix to
do anything.
Do you know what kai and kva stand for?
Steve Wendt
>>> found that adding the line ao=kai:dart to the config file fixed the
>>
>> Playing via the KAI UniAud32 interface doesn't work for a lot of us. I
>> suppose it must work on some audio chipsets, but I've heard there are
>> plenty of people who get no sound output at all (including mine).
>
> Works here with Sound Blaster 16
>
> Description Sound Blaster 16 Device Driver
> Vendor Creative Technology
> Version 1.1 02.09.1994
Quite the opposite; you are automatically using the DART interface,
because you are not using the UNIAUD driver.
Steve Wendt
> I have usually found that the solution to no sound at all is to fire up
> a mixer application such as LBMix that can unmute or raise the level of
> the wave input.
On my sound card, LBMix only affects the volume while it is running (and
yes, I do have MIX90 as a detached process). But that isn't the
problem, I have the Wave output level high enough.
> I have never been able to get unimix to do anything.
I actually have to use unimix to lower the volume in my startup.cmd,
because the defaults are way too loud. The trick is in finding the
proper ID numbers.
Running "unimix -list | more" will output a bunch of info, and you are
looking for the control named "[Wave Playback Volume]"
On my SB Live, it happens to be the first control:
Control ID: 1
Interface: virtual mixer device
Device(client): 0, subdevice (substream) 0
Name: [Wave Playback Volume]
Index: 0
Element type: integer type
Count of values: 2
Value:
Bounds: min: 0, max: 100, step: 0
value 1: 50
value 2: 50
You can see that the values can range from 0 to 100, and it defaults to
100 (on this chipset, anyway). I set both the Left and Right values to
50 like so:
unimix -id1 -cnt0 -val50
unimix -id1 -cnt1 -val50
Notice how the id number matches, but the count is lower by 1; the usage
info explains this:
-id<num> - use control num (for list or set value). Begins from 1
-val<num> - set value for control
-cnt<num> - set value for count number <num> in control. Begins from 0
I'm guessing that the first is Left and second is Right, but I haven't
had any reason to care.
> Do you know what kai and kva stand for?
I'm guessing KO's Audio Interface and KO's Video Acceleration. It might
say in the documentation contained in the library packages, available on
Hobbes. They are basically wrappers that try to be smart about what to
use for audio and video output, without the user having to figure out
the command line usage. It defeats the purpose a bit, when the
automatically chosen interface doesn't work, although that's not
necessarily the wrapper's fault.
James J. Weinkam
For some reason, I didn't see this message at the time you posted it.
My experience with the command line version of unimix with the SB Audigy was that a few controls
could indeed be set as you describe, but most of them either couldn't be set at all or only one
channel would change no matter what indices I used.
Since you have a SB live, is there any reason you are using uniaud instead of Sander's driver? I
have a SBLive in a different system and Sander's driver works perfectly.
Steve Wendt
> My experience with the command line version of unimix with the SB Audigy
> was that a few controls could indeed be set as you describe, but most of
> them either couldn't be set at all or only one channel would change no
> matter what indices I used.
If it doesn't work with unimix, I wouldn't expect it to work with other
mixers, either.
> Since you have a SB live, is there any reason you are using uniaud
> instead of Sander's driver? I have a SBLive in a different system and
> Sander's driver works perfectly.
I have a vague recollection of it not working at all (no sound) on my
particular card, but it's been a long time since I tried it. Perhaps I
did something wrong.
I assume the current version is still 0.81 from October 2001? There
were rumblings about it getting updated, but a new build hasn't surfaced
that I have noticed.
James J. Weinkam
>
> I assume the current version is still 0.81 from October 2001? There were
> rumblings about it getting updated, but a new build hasn't surfaced that
> I have noticed.
The version eCS2.0GA installs automatically if it finda a SBLive is version 0.82 dated 2006/01/11.
If you have an eCS maintenance agreement, it can be downloaded from Mensys.
LBMix shows all the controls and operates them correctly. I have been doing off the air recording
from CBC-FM with it for years.
Ruediger Ihle
> I have a vague recollection of it not working at all (no sound) on my
> particular card, but it's been a long time since I tried it.
That is well possible. Especially, if you got a newer card model.
But if it works on a particular hardware, I'd prefer it over UNIAUD.
> There were rumblings about it getting updated, but a new build
> hasn't surfaced that I have noticed.
As James noted: there is an update. It mainly features support for
IRQ > 15. There were reports that the driver won't work at all on
systems equipped with more than 2 Gig of RAM. I havn't tried that...
BTW, the source code for it is in the UNIAUD repository on Netlabs.
--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
http://www.s-t.de
Steve Wendt
> The version eCS2.0GA installs automatically if it finda a SBLive is
> version 0.82 dated 2006/01/11.
>
> If you have an eCS maintenance agreement, it can be downloaded from Mensys.
I can't seem to find it; I guess I could dig it out of the ISO.
Steve Wendt
>> I have a vague recollection of it not working at all (no sound) on my
>> particular card, but it's been a long time since I tried it.
>
> That is well possible. Especially, if you got a newer card model.
Mine is a 1102:0002, which UniAud identifies as a Dell OEM (although it
came in a retail box from NewEgg!).
> But if it works on a particular hardware, I'd prefer it over UNIAUD.
I thought Sander's driver was based on the ALSA one, anyway?
> As James noted: there is an update. It mainly features support for
> IRQ> 15. There were reports that the driver won't work at all on
> systems equipped with more than 2 Gig of RAM.
Neither of those should be a problem here.
> BTW, the source code for it is in the UNIAUD repository on Netlabs.
I had heard that, so I guess I could try to build it myself if I got
truly interested in making it work.
Ruediger Ihle
> Mine is a 1102:0002
That is the EMU10K core. So it might work... You should also
have 1102:7002, which represents the joystick port.
> which UniAud identifies as a Dell OEM (although it
> came in a retail box from NewEgg!).
That information is probably deciphered from the subsystem ID.
> I thought Sander's driver was based on the ALSA one, anyway?
No. It includes an OSS driver that was officially released
by Creative. Actually one of the better drivers written by
a company that "was forced to" supply a Linux driver because
of the hype or because their competitors did so...
However, the basic concepts of the SBLive driver were later
taken to create UNIAUD, which AFAIK was also written by Sander.
Steve Wendt
> That is the EMU10K core. So it might work... You should also
> have 1102:7002, which represents the joystick port.
Yes.
>> I thought Sander's driver was based on the ALSA one, anyway?
>
> No. It includes an OSS driver that was officially released
> by Creative.
I see.
> Actually one of the better drivers written by a company that "was
> forced to" supply a Linux driver because of the hype or because their
> competitors did so...
They got plenty of negative press about their next drivers, though:
http://www.phoronix.com/scan.php?page=news_item&px=NzE2Ng
> However, the basic concepts of the SBLive driver were later
> taken to create UNIAUD, which AFAIK was also written by Sander.
Right, that's the main reason I figured UniAud would work about the
same. In any case, thanks for the advice; I guess I should try it again
sometime.