ok, I've only had a quick look at the code, and played with a table a few times, but heres what I think is the issue...
table alloc is a fixed size
table load, reads in as much as it can... ie. will truncate if too big, but if file is smaller, will leave what ever is in the table at the end alone. I guess this would usually be zeros, if thats what you do in table init.
(but table load does not 'reset' this... so if you load that table with different samples you will end up with whats left over from last time - perhaps it should zero it out?)
now the hard bit.. table/read (I don't like how this is done, but i can understand why) , position is a fraction of the table length size. i.e. 0.5 = 50% thru the table
the advantage of this 'scheme' is it doesn't matter what your table size is, the reading code will work the same. (it has disadvantages in the maths you need to use when you want to relate it to 'real time', but such is life)
anyway, the issue I think you have, is you don't know where the end of the real buffer its... so if you run 0 to 1, your going elements 0 to 1024, but your wave possibly is only 0 to 512... in this case you need to run 0 to 0.5
as you say, the issue is... you dont have access to number of bytes read.
what we should return (as its most useful) from load, is fraction of buffer filled.
this could then be used to ensure you don't overrun the amount of the buffer used.
really to figure this all out, id have to go sit down and play with it, as i said i don't really like the way pos works, because as soon as you don't fill the entire buffer, it gets a bit more complicated about how you drive it. (its easy to do by ear using dials, but not so easy to calculate it)
but perhaps this is just because I've not used it a huge amount