Dave,
I believe you are right. Gerard Patel suggested that I run with
-debugmsg on the mm stuff and this is what came out:
**These four lines are repeated ad nauseum and filled the shell history
many times over.
**This is during the initial Analysis stage where clicks are counted,
etc.
**But no repair is attempted.
trace:mmio:mmioDosIOProc (0x40419c68, 2, 272442500,0);
trace:mmio:mmioRead (0007, 0x40622fc0, 8088);
trace:mmio:mmioDosIOProc (0x40419c68, 0, 1080176576,8088);
trace:mmio:mmioSeek (0007, 103D2484, 0);
trace:mmio:mmioDosIOProc (0x40419c68, 2, 272442500,0);
trace:mmio:mmioRead (0007, 0x40622fc0, 8088);
trace:mmio:mmioDosIOProc (0x40419c68, 0, 1080176576,8088);
trace:mmio:mmioSeek (0007, 103D2C04, 0);
trace:mmio:mmioDosIOProc (0x40419c68, 2, 272444420,0);
trace:mmio:mmioRead (0007, 0x40622fc0, 8088);
trace:mmio:mmioDosIOProc (0x40419c68, 0, 1080176576,8088);
trace:mmio:mmioSeek (0007, 103D3504, 0);
trace:mmio:mmioDosIOProc (0x40419c68, 2, 272446724,0);
trace:mmio:mmioRead (0007, 0x40622fc0, 8088);
trace:mmio:mmioDosIOProc (0x40419c68, 0, 1080176576,8088);
trace:mmio:mmioClose (0007, 0000);
**This is where I said to repair the clicks. Note that a SetBuffer
command is
**attempted, but nothing is written to disk.
trace:mmio:mmioDosIOProc (0x40419c68, 4, 0, 0);
trace:mmio:mmioSetBuffer (hmmio=0007,
pchBuf=(nil),cchBuf=0,uFlags=00000000)
trace:mmio:MMIO_SetBuffer (0x40419c68 (nil) 0 0 1)
trace:mmio:MMIO_Open ('I:\bob\recordings\Great Songs of
Christmas\raw-1_Fixed.WAV',0x40622c78, 00000002, 1);
trace:mmio:MMIO_ParseExt ("I:\\bob\\recordings\\Great Songs
ofChristmas\\raw-1_Fixed.WAV")
trace:mmio:mmioDosIOProc (0x40419cb4, 3, 5052328, 0);
trace:mmio:mmioSeek (0008, 000280CC, 0);
trace:mmio:mmioDosIOProc (0x40419cb4, 2, 164044, 0);
trace:mmio:mmioRead (0008, 0x406257c4, 4416);
trace:mmio:mmioDosIOProc (0x40419cb4, 0, 1080186820, 4416);
trace:mmio:mmioClose (0008, 0000);
**This is where I said to repair the hiss.
**Again, no disk activity.
trace:mmio:mmioDosIOProc (0x40419cb4, 4, 0, 0);
trace:mmio:mmioSetBuffer (hmmio=0008, pchBuf=(nil), cchBuf=0,
uFlags=00000000)
trace:mmio:MMIO_SetBuffer (0x40419cb4 (nil) 0 0 1)
trace:mmio:MMIO_Open ('I:\bob\recordings\Great Songs of
Christmas\raw-1_Fixed.WAV', 0x406256b0,00000002,1);
trace:mmio:MMIO_ParseExt ("I:\\bob\\recordings\\Great Songs of
Christmas\\raw-1_Fixed.WAV")
trace:mmio:mmioDosIOProc (0x404189f4, 3, 5052328, 0);
trace:mmio:mmioSeek (0009, 0000002C, 0);
trace:mmio:mmioDosIOProc (0x404189f4, 2, 44, 0);
trace:mmio:mmioRead (0009, 0x40625ecc, 256);
trace:mmio:mmioDosIOProc (0x404189f4, 0, 1080188620, 256);
trace:mmio:mmioClose (0009, 0000);
trace:mmio:mmioDosIOProc (0x404189f4, 4, 0, 0);
trace:mmio:mmioSetBuffer (hmmio=0009, pchBuf=(nil), cchBuf=0,
uFlags=00000000)
trace:mmio:MMIO_SetBuffer (0x404189f4 (nil) 0 0 1)
trace:mmsys:WINMM_LibMain 0x409ac000 0x0 0x1
[bob@kagasan Groove Mechanic]$
So the next question is, "How do we report this behavior to the Powers
That Be?"
Do the developers read this newsgroup to the point that they will catch
this post? Or is there somewhere this note should be copied to?
Thanks again for all the help,
Bob Washburne
Dave Platt wrote:
>
> In article <3C0805FE.74A968AB@concentric.net>,
> Bob Washburne <rcwash@concentric.net> wrote:
>
> >Managed mode got me past this screen. It then propted me for the
> >save-file name and that appeared to work.
> >
> >I then ran the analysis on the WAV file. That appeared to work (19,256
> >clicks detected), but when I told it to REPAIR the magic failed. What
> >should have taken over a minute happened instantly. I then said to
> >repair HISS. That normally takes over 10 minutes but again it was
> >instant. I closed up and found that the save file was only 44 bytes
> >long, enough for the WAV header, but none of the data had been written
> >out. GM has no SAVE option as it is all supposed to happen automaticly.
> >
> >Next I will try the experiment suggested by the other poster.
>
> I've run into problems very similar to this, using recent versions of
> WINE with Diamond Cut's DC-ART audio-cleanup application. This app
> used to work, with older releases of WINE, but has stopped doing so.
>
> I poked into the problem a bit, and concluded that there's a problem
> in the multimedia-buffer management code. If I recall correctly (and
> it's been a while since I investigated this code in depth), DC-ART
> opens a multimedia .WAV file in update mode, and then uses the MM
> access calls which deliver buffers full of data. It walks through
> each buffer, makes the changes it wants, marks the buffer "dirty", and
> then says "Advance to next buffer, please."
>
> What's supposed to happen (IIRC) is that the MM layer notes the fact
> that the buffer has been marked as dirty / modified, writes it back
> out to the .WAV file, and then reads in the next buffer's worth of
> data.
>
> This _used_ to be what happened. In the current WINE releases (for the
> last few months) the dirty buffers are not being written back to the
> file. I don't know just when the change occurred, but apparently
> something in the 16-bit MM code is broken.
>
> The same problem appears to occur when trying to append
> newly-generated buffers to a .WAV file. They aren't being appended.
>
> --
> Dave Platt dplatt@radagast.org
> Visit the Jade Warrior home page: http://www.radagast.org/jade-warrior/
> I do _not_ wish to receive unsolicited commercial email, and I will
> boycott any company which has the gall to send me such ads!
