Refresher Requested on MPEG4 Container and AtomicParsley

[Budgie]

Been reading all afternoon to trying and understand source of one of my 
problems when seeking within Radio 3 downloads, which for my Linn DS 
renderers I am advised by Linn is as follows:-

"The MPEG 4 container consists of a collection of boxes that encapsulate 
metadata about the audio and/or video stream contained within it. The 
audio and/or video is broken up into a sequence of chunks that are 
indexed within the MPEG 4 container in a stco (chunk offset) box.

To seek within the file, the DS seeks to the start of the chunk that 
contains the desired audio sample.

Opening the file in a hex editor and locating the stco box reveals that 
there is only one chunk offset, which points to the start of the audio 
data within the file.

So, with such a file, the DS is only able to seek to the start of the 
track."

This fits the synptoms and I assume is correct so I want to understand 
why some downloads apparently do have multiple chunk offsets and others 
only one.

Assuming the source material from BBC was OK what is the process when 
using GiP which builds the stco box (atom?) at my end.  Is this done by 
rtmpdump or GiP and where does AtomicParsley fit in?  I need a primer on 
the process.  Any suggested further reading please?

Budge