Prev: How to implement CImageList::DrawIndirect in MFC 4.2?
Next: Why is network reading slow?
From: Joseph M. Newcomer on 13 Jan 2010 10:47
See below...
On Wed, 13 Jan 2010 03:57:25 -0800 (PST), absolute <cool8511(a)gmail.com> wrote:

>When I query the length of a large .wav file( larger than 2G,about 46
>hours), mciSendCommand return the wrong value.
>My code is as below:
>
> MCI_SET_PARMS mciSetParms;
> mciSetParms.dwTimeFormat = MCI_FORMAT_SAMPLES;
> if(m_ErrorCode = mciSendCommand(m_wDeviceID,MCI_SET,MCI_WAIT|
>MCI_SET_TIME_FORMAT,
> (DWORD)(LPVOID) &mciSetParms))
> {
> return false;
> }
> MCI_STATUS_PARMS mciStatusParms;
> mciStatusParms.dwItem = MCI_STATUS_LENGTH;
>
> if(m_ErrorCode = mciSendCommand(m_wDeviceID,
>MCI_STATUS,MCI_STATUS_ITEM,
> (DWORD)(LPVOID) &mciStatusParms))
****
One of the most serious errors here is the error of actual BELIEVING the erroneous
Microsoft documentation. It makes no sense whatsoever to ever case a pointer to a DWORD,
and in the modern Platform SDK, the actual cast should be
(DWORD_PTR)(LPVOID)&mciStatusParms
or it won't compile or work in 64-bit mode. Unfortunately, Microsoft has failed utterly
to update the documentation to reflect the actual header file contents, even though the
64-bit changes are now more than a decade old. But hey, what's the rush?

A similar error occurs in the specification of the MCI_STATUS_PARMS; the CORRECT
documentation is

typedef struct {
DWORD_PTR dwCallback;
DWORD_PTR dwReturn;
DWORD dwItem;
DWORD dwTrack;
} MCI_STATUS_PARMS;

Note that if your Platform SDK does NOT use this definition, then you are using the wrong
Platform SDK and you must immediately upgrade to one that has the above definition. In
particular, if the second field is defined as a DWORD, this would be the cause of the
error.

In reporting errors like this, it is ESSENTIAL that you state
What version of VS you are using
What version of Windows you are using

Note that in addition, for this case, you need to state which version of the Platform SDK
you are using.
****
> {
> return false;
> }
>
>I suppose the return value of mciStatusParms.dwReturn should be
>1231253424, but actually,it returned 3378737072.
****
ALWAYS examine the values in hex, and give both the hex and decimal values! And in the
case where you know the correct answer, show the correct answer in hex and decimal!
****
>However, when the file is smaller than 2G, there is no problem.
****
Little-endian. Of course, it could also be an actual flaw in the mci system to ignore the
high-order 32 bits, but it is more likely an application failure.
****
>So, I think maybe it is a bug .
>Can anybody tell me is there a bug in mciSendCommand ?
****
Only after we see the values in hex, and preferrably, the memory contents of the entire
MCI_STATUS_PARMS in hex (that would be 24 bytes) is it possible to determine if the error
is in the mciSendCommand or in the application.

Fundamental truth: only the bits matter. Interpretations of the bits, such as by relying
on the debugger to always tell the truth, or using the wrong header files, can be
erroneous. So when there is the *slighest* question, you must directly examine the bits
themselves, with no intermediaries that can corrupt the interpretation.
joe
****
>Thank you very much.
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 13 Jan 2010 10:51
See below...
On Wed, 13 Jan 2010 04:36:53 -0800 (PST), absolute <cool8511(a)gmail.com> wrote:

>
>> I know nothing about the mci APIs but if you convert those values to
>> hex you can probably see what's happened. It looks like something has
>> sign extended a value inappropriately?
>>
>> Dave
>
>Yes, I see. The two results are just different between the sign bit.
>
>But the result is returned by the mciSendCommand API function. I debug
>and find the problem.
>So I think it is a bug. But I am not so sure.
>
>PS: Again, I did a experiment using a 1.8G file and a 2.2G file. The
>result returned by 1.8G file is correct, but result of 2.2G file is
>wrong.
****
They cannnot differ "in the sign bit" because the value is a DWORD, which *has no sign
bit*.

Any signed interpretation would be erroneous.

Note also that since it is a DWORD_PTR, it means that you cannot return a length > 4.2GB
in Win32, and this therefore represents an fundamental design error in the API. What, you
expected that the API would be *compatible* with other than a 16-bit system? (Sadly, you
should expect it to work; the fact that it does not is a total failure on the part of
Microsoft)
joe
****
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 13 Jan 2010 11:17
I have added the documentation failures to my "errors and omissions" document.
joe

On Wed, 13 Jan 2010 04:36:53 -0800 (PST), absolute <cool8511(a)gmail.com> wrote:

>
>> I know nothing about the mci APIs but if you convert those values to
>> hex you can probably see what's happened. It looks like something has
>> sign extended a value inappropriately?
>>
>> Dave
>
>Yes, I see. The two results are just different between the sign bit.
>
>But the result is returned by the mciSendCommand API function. I debug
>and find the problem.
>So I think it is a bug. But I am not so sure.
>
>PS: Again, I did a experiment using a 1.8G file and a 2.2G file. The
>result returned by 1.8G file is correct, but result of 2.2G file is
>wrong.
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: David Ching on 13 Jan 2010 11:33
"absolute" <cool8511(a)gmail.com> wrote in message
news:9eb70c3b-0a11-4bc1-87ff-c54df4910915(a)34g2000yqp.googlegroups.com...
> When I query the length of a large .wav file( larger than 2G,about 46
> hours), mciSendCommand return the wrong value.

As Alexander says, many audio apps had issues with files over 2 GB. Some
worked correctly, some didn't. So the issue in general has occurred many
times in history. In addition, I do not think MCI is officially supported
anymore. They didn't officially deprecate it, but it's not guaranteed to
always work anymore. I ran into this issue when some version of Media
Player, I think it was 8 or 9, came out and my MCI code to play a .mp3 file
didn't work anymore, even though Media Player played it OK.

A quick test would be to fire up MPLAY32.EXE which is the old Media Player
that strictly uses MCI commands. See if your .wav file plays in that.
MPLAY32.EXE is included in WinXP (just go to Start menu and type
"mplay32.exe" in the Run box). Unfortunately, it's not in Win 7 and maybe
not in Vista.

-- David

From: absolute on 13 Jan 2010 20:28
> A quick test would be to fire up MPLAY32.EXE which is the old Media Player
> that strictly uses MCI commands.  See if your .wav file plays in that.
> MPLAY32.EXE is included in WinXP (just go to Start menu and type
> "mplay32.exe" in the Run box).  Unfortunately, it's not in Win 7 and maybe
> not in Vista.
>
> -- David

I had just tested with the MPLAY32.EXE. The result is, while open wav
file larger than 2G, MPLAY32.EXE can not show the total length
correctly.
So maybe it is indeed the API has a bug while handling the large file.

But can anybody tell me which APIs have the similar functions like
MCI.
I want to play .wav file and query some parameters in it.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: How to implement CImageList::DrawIndirect in MFC 4.2?
Next: Why is network reading slow?