Ploblems with mciSendString
Dave O.
I don't know if I've made a mistake somewhere or if there is a systemic
problem with mciSendString.
Some MP3 files if played from 0 are silent, but if played from a second or
so in are OK. The amount of offset required varies in the few files I've
checked from ~140ms to ~1200ms.
Have I missed something here?
Declaration:
String, ByVal lpstrReturnString As String, ByVal uReturnLength As Integer,
ByVal hwndCallback As Integer) As Integer
To play a file:
retVal = mciSendString("Open " & EnquoteFileName(Filename) & " type
mpegvideo alias MainMedia", "", 0, 0)
Call mciSendString("setaudio MainMedia volume to " & CStr(VolValue), 0, 0,
0)
strRet = "play MainMedia"
If Playfrom_ms > 0 Then strRet = strRet & " from " & CStr(Playfrom_ms)
retVal = mciSendString(strRet, "", 0, 0)
(Where EnquoteFileName put quotes around the file name if it has spaces,
Filename, VolValue & Playfrom_ms should all be obvious)
To close:
Call mciSendString("Close MainMedia", "", 0, 0)
I also tried these:
Call mciSendString("set MainMedia time format ms", "", 0, 0)
This made no difference as far as I could tell.
strRet = Space(16)
call mciSendString("status MainMedia start position", strRet, 16, 0)
I had great hopes for this one, but it always seems to return 0 (H30)
followed with NULLs.
I've looked with a hex viewer at the files that work correctly and those
that don't and I cannot see any obvious distinction, there are files from
the same CD which would probably have all been ripped together, some will
work while others don't. I've also tried the code on different machines from
different suppliers in case it was a problem with the PC, but in both the
Toshiba off-line clean install and in the Sony on-line up-to-date machine
the problem manifested itself.
Any suggestions are welcome.
Regards - Dave O.
Dave O.
title.
Dave O.
The declaration should have read:
Public Declare Function mciSendString Lib "winmm.dll" Alias
"mciSendStringA" (ByVal lpstrCommand As String, ByVal lpstrReturnString As
Jim Mack
You say they're 'silent' but does that mean they actually play with no
output? If you periodically get the current file position, does it
increase from 0?
Why bother with the test for 0 -- why not use "from" in every play
command? Does that change things?
I don't know if this has changed with newer OS's, but in the past it
was true that mciSendString could not reliably handle long file names
/ paths, even with quoting -- you had to use the short versions of
names and all path segments. I believe Karl Peterson has an example of
how to convert an entire path, at his web site.
Not that it's causing this, but in your Declare, all "integer" should
be "long".
--
Jim Mack
Twisted tees at http://www.cafepress.com/2050inc
"We sew confusion"
Thorsten Albers
<uMGa05e...@TK2MSFTNGP02.phx.gbl>...
> Integer
No, it should have read:
Public Declare Function mciSendString _
Lib "winmm.dll" _
Alias "mciSendStringA" _
( _
ByVal lpstrCommand As String, _
ByVal lpstrReturnString As String, _
ByVal uReturnLength As Long, _
ByVal hwndCallback As Long _
) As Long
VB Integer = C short = 2 Bytes
VB Long = C int/long = 4 Bytes
--
Thorsten Albers
albers (a) uni-freiburg.de
Dave O.
"Jim Mack" <jm...@mdxi.nospam.com> wrote in message
news:%23MB$hDfNKH...@TK2MSFTNGP04.phx.gbl...
> Dave O. wrote:
>
> You say they're 'silent' but does that mean they actually play with no
> output? If you periodically get the current file position, does it
> increase from 0?
Certainly does, I have a timer doing a Status which updates a slider, if I
leave it playing silently to the end of the file, it reacts exactly the same
as if it was making the noises.
> Why bother with the test for 0 -- why not use "from" in every play
> command? Does that change things?
Does not seem to make any difference, but hey this mci stuff is all new to
me :-)
> I don't know if this has changed with newer OS's, but in the past it
> was true that mciSendString could not reliably handle long file names
> / paths, even with quoting -- you had to use the short versions of
> names and all path segments. I believe Karl Peterson has an example of
> how to convert an entire path, at his web site.
I considered using short path names but I really can't see how that would
make a difference as the files play correctly if started from beyond the
start. I'll check this by copying a "duff" file to a folder with a short
name with no spaces and renaming the file to a 8.3 format name, you never
know, it might make a difference!
> Not that it's causing this, but in your Declare, all "integer" should
> be "long".
I wondered about that, I'll change them all just for consistancy, I remember
that long debate about long v integer and we don't want to go there again do
we boys and girls?
Thanks.
Dave O.
Dee Earley
It's not a debate...
For a given api call in any particular language, it is either right or
wrong...
--
Dee Earley (dee.e...@icode.co.uk)
i-Catcher Development Team
iCode Systems
Dave O.
"Dee Earley" <dee.e...@icode.co.uk> wrote in message
news:%23vWcXGh...@TK2MSFTNGP04.phx.gbl...
> On 15/09/2009 12:07, Dave O. wrote:
>> "Jim Mack"<jm...@mdxi.nospam.com> wrote in message
>> news:%23MB$hDfNKH...@TK2MSFTNGP04.phx.gbl...
>>> Dave O. wrote:
>>> Not that it's causing this, but in your Declare, all "integer" should
>>> be "long".
>>
>> I wondered about that, I'll change them all just for consistancy, I
>> remember
>> that long debate about long v integer and we don't want to go there again
>> do
>> we boys and girls?
>
> It's not a debate...
> For a given api call in any particular language, it is either right or
> wrong...
The declaration I used was directly from the MS API viewer, but we know
there are a few errors in there, this must be one of those.
Curiously the version I have here at work (the program is a personal one at
home) has them all as longs - ce la vie.
The "debate" I refer to is in the microsoft.public.vb.gereral.discussion
group, 28 July 2009 - "Integer or Long"
Regards
Dave O.
Stuart McCall
news:uMGa05e...@TK2MSFTNGP02.phx.gbl...
If I'm not mistaken, uReturnLength and hwndCallback should both be Longs.
(Can't check on this machine, this is just from memory)
Dave O.
Stuart & Thorsten
I'll change them tonight, it might rectify this issue - I'll let you know
tomorrow.
Dave O.
Jim Mack
> "Jim Mack" wrote...
>> Dave O. wrote:
>>
>> You say they're 'silent' but does that mean they actually play
>> with no output? If you periodically get the current file position,
>> does it increase from 0?
>
> Certainly does, I have a timer doing a Status which updates a
> slider, if I leave it playing silently to the end of the file, it
> reacts exactly the same as if it was making the noises.
Then everything else I mentioned can be ignored. I presume you've
tried setting the volume after starting play, just in case?
Needless to say this is not normal behavior, and I've never
encountered it. If the problem follows the media to another computer,
it would be worth looking at it with an MP3 analyzer. If not, I'd
re-install a codec pack and audio / DX drivers.
--
Jim Mack
Twisted tees at http://www.cafepress.com/2050inc
"We sew confusion"
Dave O.
> Then everything else I mentioned can be ignored. I presume you've
> tried setting the volume after starting play, just in case?
I have a slider to control the volume while the media is playing, I 've
tried moving that while the file is "playing" but to no avail, however I've
not tried setting it in code just afer sending "play" instead of as
currently, before. I'm willing to try anything so I'll try changing the
order things happen in.
> Needless to say this is not normal behavior, and I've never
> encountered it.
I'm glad to hear that because it's inconceivable than I'm the first to
encounter such a problem so the fault myst be with something I've done
rather than with the mci itself. That's good because it means the problem
can be solved.
>If the problem follows the media to another computer,
> it would be worth looking at it with an MP3 analyzer. If not, I'd
> re-install a codec pack and audio / DX drivers.
I think my next step is to make a small test app with just the playing code
in isolation and see if I still have the problem, it should also be a
simpler way to test suggestions. I'll look around for an analyser to see if
the MP3s are badly broken and if they are if there's anything simple fix.
Many Thanks
Dave O.
Dave O.
"Stuart McCall" <smc...@myunrealbox.com> wrote in message
news:OcrN2ThN...@TK2MSFTNGP02.phx.gbl...
Last night I changed all the Integers to Longs in the declaration, I also
renamed some files to 8.3 compatible files with DOS compatible paths (no
spaces) and tried a few ideas of my own, all to no avail.
Oh well, I fix this, see if I don't.
Thanks for your help
Dave O.
Thorsten Albers
> Last night I changed all the Integers to Longs in the declaration, I also
> renamed some files to 8.3 compatible files with DOS compatible paths (no
> spaces) and tried a few ideas of my own, all to no avail.
Just a short addition which unfortunately very likely will >>not<< solve
the problem: Some (especially) C/C++ developers handle strings very badly
so that a NULL string in their code is treated other than an empty string,
even if the string length is given as 0.
For 'lpstrReturnString' you are passing an empty string everywhere in your
code. Change this to 'vbNullString'.
Dave O.
"Thorsten Albers" <alber...@THISuni-freiburg.de> wrote in message
news:%23pSlnZr...@TK2MSFTNGP04.phx.gbl...
Yes, I wondered about that one too, I have tried a few different values for
that parameter, but there's no reason not to give it another go alongside
all the other thing I'm trying out.
Thanks
Dave O.
Norm Cook
Dave, don't know if you solved your problem but here's some
code that works for me. In one of the posts above I think you
mentioned checking the MP3's with another player. That is a good
idea, has save me some grief in the past. Even MS Windows Media
Player serves here, but I keep an older version of Winamp (v2.95)
installed. http://www.oldversion.com/Winamp.html
(watch wordwrap)
Option Explicit
Private Const WS_CHILD = &H40000000
Private Declare Function mciSendString Lib "winmm.dll" Alias
"mciSendStringA" (ByVal lpstrCommand As String, ByVal lpstrReturnString As
String, ByVal uReturnLength As Long, ByVal hwndCallback As Long) As Long
Private Declare Function mciGetErrorString Lib "winmm.dll" Alias
"mciGetErrorStringA" (ByVal dwError As Long, ByVal lpstrBuffer As String,
ByVal uLength As Long) As Long
Private Declare Function GetShortPathName Lib "kernel32" Alias
"GetShortPathNameA" (ByVal lpszLongPath As String, ByVal lpszShortPath As
String, ByVal cchBuffer As Long) As Long
Private Sub Form_Load()
'important: an app that closes with an
' mci error will persist to the next launch
' i. e. didn't get closed - see Form_Unload
SendMCIString "close all", True
'********change next line**********
PlayMP3 "X:\SomeFolder\SomeSong.mp3" 'change this***********
End Sub
Private Sub Form_Unload(Cancel As Integer)
SendMCIString "close all", True
End Sub
'Wrapper for mcisendstring
Private Function SendMCIString(ByVal Cmd As String, Optional ByVal CheckErr
As Boolean = False) As Boolean
Dim Ret As Long
Dim ErrBuff As String * 260
Ret = mciSendString(Cmd, vbNullString, 0&, 0&)
If Ret Then
If CheckErr Then
mciGetErrorString Ret, ErrBuff, 260
MsgBox Left$(ErrBuff, InStr(ErrBuff, Chr$(0)))
End If
End If
SendMCIString = CBool(Ret)
End Function
Private Function ShortPath(ByVal LongPath As String) As String
Dim Ret As Long
Dim Buff As String * 260
Ret = GetShortPathName(LongPath, Buff, 260)
ShortPath = Left$(Buff, Ret)
End Function
Private Sub PlayMP3(ByVal MP3Path As String)
Dim OpenString As String
MP3Path = ShortPath(MP3Path)
If Len(MP3Path) Then
OpenString = "open " & MP3Path & _
" type MPEGVideo Alias mp3 parent " & _
hWnd & " Style " & WS_CHILD
If Not SendMCIString(OpenString, True) Then
SendMCIString "play mp3", False
Else
MsgBox "Problem with OpenString" & vbNewLine & OpenString
End If
Else
MsgBox "Problem with Mp3 Path"
End If
End Sub
'other functions
Private Sub StopMP3()
SendMCIString "stop mp3", False
End Sub
Private Sub PauseMP3()
SendMCIString "pause mp3", False
End Sub
Private Sub ResumeMP3()
SendMCIString "resume mp3", False
End Sub
Dave O.
Thanks, I'll try your code verbatim, if that works where mine does not I'll
have a good starting point to determine what stupid thing I have done. If
your code shows the same problem then I better look to see if a large swathe
of my MP3 collection has got corrupted somehow.
Regards
Dave O.
"Norm Cook" <norm...@cableone.net> wrote in message
news:e5i17NsN...@TK2MSFTNGP02.phx.gbl...
Dave O.
Thanks, I tried your code exactly as posted and it made no difference so I
am forced to conclude the problem lays with the media and not the program.
My next step is to get an analysis program and find out exactly what's wrong
with the files and see if there is any way to detect it. For the time being
I've added a work-around and later I'll look at either re-ripping the
tracks or re-encoding the existing files.
Once again, thanks to everybody who contributed. All help is gratefully
received.
Dave O.
Jim Mack
> "Norm Cook" wrote...
>
> Thanks, I tried your code exactly as posted and it made no
> difference so I am forced to conclude the problem lays with the
> media and not the program.
You can conclude that only after you've done a re-install of audio
drivers, codecs, and DirectX bits.
How many audio devices do you have installed (per the Audio tab in the
Sounds & Multimedia Control Panel)? It could be that for some reason
MCI is rendering these to another device. Something like G-Spot will
analyze the codec and devices actually used ("Proposed Codec
Solutions - MS A/V").
Also under the Audio c/p is an Advanced / Performance tab that lets
you deselect DirectX ("none" for HW acceleration). All this is worth a
look.
Dave O.
"Jim Mack" <jm...@mdxi.nospam.com> wrote in message
news:u4Nki64N...@TK2MSFTNGP04.phx.gbl...
> Dave O. wrote:
>> "Norm Cook" wrote...
>>
>> Thanks, I tried your code exactly as posted and it made no
>> difference so I am forced to conclude the problem lays with the
>> media and not the program.
>
> You can conclude that only after you've done a re-install of audio
> drivers, codecs, and DirectX bits.
I've tested the code with suspect MP3 files on totally differnt machines -
Diffenrent vendor, clean XP install/old updated XP install, different
Service Pack level, different codec selection, but the fault was exactly the
same. I'll look at the (allegedly) dodgy files with an analyser and if it
turns out the the files are OK then I'll look again at the codecs but I am
reasonbly certain about this.
Anyway, thanks for taking an interest.
Dave O.
Jim Mack
> "Jim Mack" <jm...@mdxi.nospam.com> wrote in message
> news:u4Nki64N...@TK2MSFTNGP04.phx.gbl...
>> Dave O. wrote:
>>> "Norm Cook" wrote...
>>>
>>> Thanks, I tried your code exactly as posted and it made no
>>> difference so I am forced to conclude the problem lays with the
>>> media and not the program.
>>
>> You can conclude that only after you've done a re-install of audio
>> drivers, codecs, and DirectX bits.
>
> I've tested the code with suspect MP3 files on totally differnt
> machines - Diffenrent vendor, clean XP install/old updated XP
> install, different Service Pack level, different codec selection,
> but the fault was exactly the same. I'll look at the (allegedly)
> dodgy files with an analyser and if it turns out the the files are
> OK then I'll look again at the codecs but I am reasonbly certain
> about this.
I would definitely try dropping the HW Acceleration on the Audio tab
to "none" first. This is going to be at max by default on any machine
you try.
Otherwise, G-Spot is your friend. Good luck.