Re: [non-daw] *.peak files > 10x .wav

[ Thread Index | Date Index | More lists.tuxfamily.org/non-daw Archives ]


On Mon, Feb 22, 2010, John Murphy wrote:
> The huge peak data file problem seems to be limited to 64 bit
> operating systems. I've just built non-daw on an old OS I had
> left on a partition. Dropping the same large audio file as I
> tested with previously results in the completion of the peak
> data file in a few minutes, with a size of about 2GB.
> 
> Looking at the first 160 from the 'good' file (32bit):
> 
> 00000000  00 01 00 00 70 f9 49 01  00 00 f2 bb 00 00 e8 3c  |....p.I........<|
> 00000010  00 80 09 bc 00 c0 fc 3c  00 20 15 bd 00 00 00 00  |.......<. ......|
> 00000020  00 60 29 bd 00 00 a0 39  00 c0 c6 bc 00 60 38 3d  |.`)....9.....`8=|
> 00000030  00 80 de bc 00 00 54 3d  00 c0 e5 bc 00 80 51 3d  |......T=......Q=|
> 00000040  00 e0 05 bd 00 c0 6f 3d  00 00 04 bd 00 00 00 38  |......o=.......8|
> 00000050  00 40 14 bd 00 00 f0 39  00 00 b8 ba 00 e0 47 3d  |.@.....9......G=|
> 00000060  00 00 2e bb 00 e0 64 3d  00 80 f8 bc 00 00 29 3c  |......d=......)<|
> 00000070  00 e0 0a bd 00 80 3f 3c  00 00 d4 bc 00 60 0f 3d  |......?<.....`.=|
> 00000080  00 80 f0 bc 00 c0 21 3d  00 80 eb bc 00 60 4e 3d  |......!=.....`N=|
> 00000090  00 c0 03 bd 00 00 6b 3d  00 80 01 bd 00 00 00 00  |......k=........|
> 
> Compared to the first 160 bytes from the original test (64bit):
> 
> 00000000  00 01 00 00 00 00 00 00  70 f9 49 01 00 00 00 00  |........p.I.....|
> 00000010  00 00 f2 bb 00 00 e8 3c  00 80 09 bc 00 c0 fc 3c  |.......<.......<|
> 00000020  00 20 15 bd 00 00 00 00  00 60 29 bd 00 00 a0 39  |. .......`)....9|
> 00000030  00 c0 c6 bc 00 60 38 3d  00 80 de bc 00 00 54 3d  |.....`8=......T=|
> 00000040  00 c0 e5 bc 00 80 51 3d  00 e0 05 bd 00 c0 6f 3d  |......Q=......o=|
> 00000050  00 00 04 bd 00 00 00 38  00 40 14 bd 00 00 f0 39  |.......8.@.....9|
> 00000060  00 00 b8 ba 00 e0 47 3d  00 00 2e bb 00 e0 64 3d  |......G=......d=|
> 00000070  00 80 f8 bc 00 00 29 3c  00 e0 0a bd 00 80 3f 3c  |......)<......?<|
> 00000080  00 00 d4 bc 00 60 0f 3d  00 80 f0 bc 00 c0 21 3d  |.....`.=......!=|
> 00000090  00 80 eb bc 00 60 4e 3d  00 c0 03 bd 00 00 6b 3d  |.....`N=......k=|
> 
> Shows the peak data getting further and further offset...
> 
> -- 
> HTH, John.
> 
> 

Good work! thanks. That helps narrow the problem down quite
a bit. Should just require changing a type in the peak
generation/read code to force 32-bit word size. I've made a
note of it.

-- 
Feb 23 2010,
John Moore Liles



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/