Re: Binary Reader Scanning for string - C# Discussion Boards

Re: Will Using Console.Beep(); Too Much Damage Your Computer?

9-Jun-08 17:49

Mark Brock

Click here to view my blog

Joe Woodbury9-Jun-08 19:30

Joe Woodbury

9-Jun-08 19:30

Eventually yes, but the other components will have already failed by that point so it's irrelevant.

Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke

Re: Will Using Console.Beep(); Too Much Damage Your Computer?

Ashfield9-Jun-08 21:24

Ashfield

9-Jun-08 21:24

It will if you sit near me! Smile | :)

Bob
Ashfield Consultants Ltd

Bind a Datatable With an Hyperlink Column To a GridView

HatakeKaKaShi9-Jun-08 16:51

HatakeKaKaShi

9-Jun-08 16:51

Hey guys got a problem here

I create a datatable manually and bind in to the gridview. It can be done
But here the issue how to create a hyperlink column manually in datatable
and a button column in datatable

any advise or guide
i will seriously deeply apperciate the help

Thanks a million Bros and Sis

KaKaShi HaTaKe

Binary Reader Scanning for string

Jammer9-Jun-08 15:12

9-Jun-08 15:12

Hi All,

I've having some problems using a Binary Reader to find a chunk of format information in a WAV file. Basically everything is working fine with my reader using the standard data chunks, thje problem starts when I parse the file for the actual "data" chunk. The WAV standard is a pretty loose file format and allows for all manner of chunks inbetween the basic information and where the actual WAVE data begins. Each chunk has an ID which is either "RIFF", "fmt ", other random ones, then there is a "data" chunk located at a variable location. The code below is shocking, I know hence why i'm here, it works for some files but its also horribly inefficient and is in no way reliable. Can someone enlighten me as to a sure fire way of getting to this "data" chunk?

private void LocateDataChunk(BinaryReader bReader)
{
    int _pos = 0
    for (int i = _pos; i < (int)riffChunk.dwFileLength; i++)
    {
        bReader.BaseStream.Position = i;
        try
        {
            dataChunk.sChunkID = new string(bReader.ReadChars(4));
            if (dataChunk.sChunkID == "data")
            {
                dataChunk.dwChunkSize = bReader.ReadUInt32();
                return;
            }
        }
        catch (Exception ex)
        {
        }
    }
}

riffChunk.dwFileLength is the uint byte count of the file.

Any help on this would be great.

Jammer

Going where everyone here has gone before! Smile | :)

Insincere Dave9-Jun-08 17:21

Insincere Dave

9-Jun-08 17:21

I don't think the code you posted is that bad. You could improve it a little by keeping track of the previous characters so you don't need to reset the position. I did some unscientific tests using a 20mb MemoryStream with the data part at the end.

Original 1x
Keep track of previous characters using an array like a circular queue. ~1.8x speedup
Same as above but treating characters as bytes. ~8x speedup to original
Read whole file into byte[]. ~20x speedup

long pos = 0;
byte[] previous = bReader.ReadBytes(4);

for (long i = bReader.BaseStream.Position; i < length; i++)
{
    byte current = bReader.ReadByte();
    previous[pos++ % 4] = current;

    if (previous[pos % 4] == 'd' && previous[(pos + 1) % 4] == 'a' && previous[(pos + 2) % 4] == 't' && previous[(pos + 3) % 4] == 'a')
    {
        dataChunk.sChunkID = "data";
        dataChunk.dwChunkSize = bReader.ReadUInt32();
        return;
    }
}

It would seem the text encoding has the biggest impact, I couldn't find many wav files to test so I don't know if my code behaves any better than yours does, of the ones I tested the actual speed impact was negligible maybe something else was causing the slowdown?
Check the files that aren't working in a hex editor (in VS Open File > Open Dropdown > Binary Editor) and make sure you take care between int/unit/long for positions, file lengths e.t.c and the endianess of what your reading.

Think you've already seen this article.

Jammer10-Jun-08 3:22

10-Jun-08 3:22

Thanks for this dave, i'll try your version later. The problem I'm having is that On some files it was taking an extraordinary amount of time to find the "data" string. I was kind of hoping there was some other way to quickly scan to this chunk and get the position rather than try{}catch{} at every position. Reading the file into memory isn't an option as some of the files could be 100mb+ wav files ...

Anyway, i'll try your version later and see how it performs. Really appreciate that. Thank you!

Cheers,

Jammer

Going where everyone here has gone before! Smile | :)

Guffa10-Jun-08 12:02

Guffa

10-Jun-08 12:02

Why on earth are you reading the file four characters at a time, looking for an identifier? The file is organised into chunks, where the four character identifier is followed by an int containing the size of the chunk. Just read the chunk size and use that to skip to the next chunk, instead of reading throught the chunk four characters at a time.

Besides, there is no guarantee that the chunk size is a multiple of four, so using that method you may just as well miss the next identifier.

Also, you are catching exceptions and just ignoring them, you should never do that. If you re-throw the exception, you will probably find that when the method takes long time to run, you have missed the data identifier so that you are reading the entire file, and then continue to try to read way past the end of the file, as your loop runs for four times the size of the file.

Despite everything, the person most likely to be fooling you next is yourself.

Jammer10-Jun-08 12:17

10-Jun-08 12:17

Hi Guffa,

This is the first time I've ever attempted dealing with files like this. I'm a C# newbie (as you can tell) your points about this are sound (scuse the pun) and make complete sense.

If you have the time is there any chance you could provide a code example? I'm going to go and have a play with this idea and see what I can do.

Much appreciated.

Cheers,

Jammer

Going where everyone here has gone before! Smile | :)

Jammer10-Jun-08 13:36

10-Jun-08 13:36

Hmm ... it doesn't appear to be as simple as you suggest.

I have pieced together some code that performs as you suggest and i'm testing it with some wav files I have here ... after the initial "RIFF" chunk and the "fmt " chunk I have a file here with a "fact" chunk

public class factChunk
{
    public string sChunkID;
    public uint dwChunkSize;
    public uint dwNumSamples;
}

this particular file reports its factChunk ChunkSize as 4 ...

Looking at this file in Riffpad the chunks are detailed as

RIFF = len 611548 offset=0
fmt = len 18 offset 20
fact = len 4 offset 46
smpl = len 54 offset 58
data = len 611348 offset 120
INFO = len 80 offset 611480
INAM = len 17 offset 611488
IPRD = len 15 offset 611514
ISFT = len 17 offset 611538

I don't see how to make these correlate to positions leading on from each other? Can anyone help?

I'm reading in the RIFF and fmt chunks as they are standard to all wav files, then i'm kicking off a method that attempts to find the other chunks, but its completely failing to do so based on the reported chunk sizes.

public void FindNextChunk(BinaryReader bReader, long offset)
{
    _startPos = bReader.BaseStream.Position;
    genchunk.ChunkID = new string(bReader.ReadChars(4));
    genchunk.ChunkSize = bReader.ReadUInt32();
    FindNextChunk(bReader, _startPos + (long)genchunk.ChunkSize);
}

Jammer

Going where everyone here has gone before! Smile | :)

Guffa10-Jun-08 20:32

Guffa

10-Jun-08 20:32

The chunk size is not including the identifier and chunk size, so you would have to add 8 to your calculation.

Or simply go from the current position:

bReader.BaseStream.Seek((long)genchunk.ChunkSize, SeekOrigin.Current);

Despite everything, the person most likely to be fooling you next is yourself.

Jammer11-Jun-08 9:21

11-Jun-08 9:21

Brilliant!! Thanks for this Guffa, much appreciated!

Jammer

Going where everyone here has gone before! Smile | :)

Form Inheritance

Dirso9-Jun-08 13:31

9-Jun-08 13:31

Hi,

I created a Form with a menu bar with a few menu itens pre-made. I've setted the Modifiers to "protected" (or even to public) but when I create an inherited form from this one, the VS (2005) Designer doesn't allow me to add menu itens. Is there any way to make it work?

Thanks,
Dirso

MarkB7779-Jun-08 13:48

9-Jun-08 13:48

You remembered that there's "Menu Items", and a "Menu Strip" right?

The menu strip needs to be set to protected or public.

Cheers,

Mark Brock

Click here to view my blog

Dirso9-Jun-08 14:32

9-Jun-08 14:32

That' what I did. Frown | :(

I can't understand why that "lock" symbol keeps showing in the designer (and all its properties are disabled in the properties window.

Thanks,
Dirso

MarkB7779-Jun-08 16:16

9-Jun-08 16:16

Hmmm works fine for me.

Care to post some code?

Mark Brock

Click here to view my blog

Dirso10-Jun-08 2:05

10-Jun-08 2:05

I uploaded the solution source code (VS2005) to my website - since I didn't know what code to post - it's only 27k. I hope you can help me.
http://www.jrsoftwares.com.br/JRFW.zip

Thanks,
Dirso

MarkB77710-Jun-08 2:28

10-Jun-08 2:28

This worked fine for me:

<br />
<br />
mmMain.Items.Add(new ToolStripMenuItem("Testing"));<br />
<br />

I can't spot why it's breaking on your end.

Mark Brock

Click here to view my blog

Dirso10-Jun-08 2:47

10-Jun-08 2:47

Hi,

Not breaking, it works for me too. My question is about the designer: why can't I edit the control at design time?

Thanks,
Dirso

MarkB77710-Jun-08 2:59

10-Jun-08 2:59

Opps I've misinterpreted your question.

Your problem is one that is often brought up.

this might help.

There is a good article on this topic somewhere on codeproject as well, but the search is not working for me at the moment.

Cheers,

Mark Brock

Click here to view my blog

Dirso10-Jun-08 10:30

Re: Form Inheritance (still can't edit)

10-Jun-08 10:30

Hi,

Thanks for your help. I think this is the best I can get from the current VS version, hopefully it gets better with 2008 or 2100 Smile | :)

Thanks a lot,
Dirso

Dirso10-Jun-08 12:20