Okay. What else can you report about the integrity of the WAV files? When you load them into a somewhat capable audio player, is the displayed playtime correct? In that case, the internal file size in the WAV header would be correct. What do you see at the end of the files when you display them in a hex-editor (e.g. khexedit)? Could it be that they have ~1 GiB of zeroes at the end?
They are shared via Samba, and I've created playlists with MusicMatch Jukebox showing all files. Every file seems to have a reasonable file size, and playing one or two songs gives no errors plus the playtime is accurately reported.
I could not open the file with khexedit, since it complained about insufficient memory (I have only 256MB of RAM in this machine). But the theory of it actually having spaces or zeroes at the end does not seem logical: what on God's green Earth would tack on 1GB of zeroes at the end, and if so, why does "ls -sh" report the file size correctly? If this space was indeed being used, then 63GB would have _actually_ expanded to 1.6TB, instead of just _apparently_ having done so.
And then it wouldn't fit on the 120GB disk, whereas "df -m" shows the expected 45GB free and I just moved 10GB to that drive as a test with no problems. AFAICS, that 1TB discrepancy between listings does seem to be a phantom... but from what, how, why, and how to fix it?
I have no idea how to even start looking for this one, but while you guys attempt to help me, is there perhaps some docs I should be reading at the same time?
Thanks,
-- Rodolfo J. Paiz [EMAIL PROTECTED]
-- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
