Re: [ReZound-users] Loading problem with a smallish raw

[John O. <jo...@mc...>]

Davy,

It appears that the standard Gentoo ebuilds for both audiofile (maintainer 
vapier) and rezound (maintainer ribosome) default to enable-largefile. 

So I went to the cvs with:

cvs -z3 -d:pserver:ano...@cv...:/cvsroot/rezound co rezound

but I think I got the same version that Gentoo is building (0.11.1 if the 
number means anything). It bootstrapped, configured and made without errors, 
although I have not located where the enable-largefile flag is set.  I still 
get the following error, and the file Open window will not display the file 
mentioned in the message. (I have to call the file from the commandline along 
with the cvs copy of rezound to get the error.)

error - void CPath::setPath(const std::string&) -- error stat-ing path name -- 
'M4R200504211930Ed9624wIntrosApplse.raw' -- Value too large for defined data 
type

I tried the Gentoo compiled rezound which got slightly different errors (along 
with finding the tmp files of the cvs compiled one):

file: M4R200504211930Ed9624wIntrosApplse.raw
warning -- libaudiofile reports that M4R200504211930Ed9624wIntrosApplse.raw 
contains 18446744073709551615 sample frames yet the file is most likely not 
large enough to contain that many samples.
Loading what can be loaded.
error - void TPoolFile<_l_addr_t, _p_addr_t>::insertSpace(unsigned int, 
l_addr_t, l_addr_t) [with _l_addr_t = sample_pos_t, _p_addr_t = uint64_t] -- 
insufficient logical address space to insert 18446744073709551615 elements 
into pool (poolId: 1 name: 'Channel 1' byte size: 0 byte alignment: 4)

I thought that the standard Gentoo version of ReZound could handle large files 
after we looked at that last year. But since then, I have been using ReZound 
to edit the 44/16 version of my recordings. Now that it is possible to burn 
DVD-As, it sure would be nice to do the slicing and dicing at 96/24, so all 
versions would be the same, regardless of delivery medium, with only one 
editing session needed. 

Thanks again for a great editor,

John