In article <[email protected]>, Budgie <[email protected]> wrote: > 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:-
[snip] > 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. I'm not sure someone using a hex editor would be the best way to establish that. They could easily find some details and miss others. However they don't seem to mention that the file should be fixed-rate, which should make life easier for a renderer, or a for a 'fix' program. (Assuming the payload itself isn't garbled, which may occur. I've seen that once or twice here, I think. But this should be rare.) > 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. What Vangelis has written in reply should be a good basis for what you can try. My experience - with DVB-T2 streams - is that the behaviour of various versions of ffmpeg/avconc did vary. These streams aren't quite the same as a downloaded file because they are grabbed sections of a stream, whereas gip essentially fetches a pre-defined file. But... In general, using a method like the one Vangelis exampled should 'clean' the result and insert any needed timestamp info that may have gone awol. However I found that in some cases this didn't work properly. So I could get some cases where the result played from the start, and the elapsed time and duration shown by VLC seemed fine. But any attempt to 'jump' to a different time caused the values to be wrong, or zero, and playback might crash. In some cases 'cleaning' of these seems impossible, but I suspect these were grabbed with too low a UHF signal/noise ratio so have flaws in the data stream that ffmpeg, etc, can't understand or fix. That said the DVB-T/T2 standards *use* seemed a bit of a wild west a few years ago. 8-] So it is possible that either the files you fetched were sufficiently 'broken' and/or the version of ffmpeg/avcon you were using simply didn't sort this out immediately after fetching. Another pass though a newer ffmpeg might fix it, though. If not, as audio, you can finally bail out and convert to lpcm wav.The standard wave format just has a header followed by the lpcm sample values. If that sounds OK, it can be re-encoded if you wish to save space. Although I would recommend a loss-free method like flac to avoid needless reduction in quality if you get to this stage. Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html _______________________________________________ get_iplayer mailing list [email protected] http://lists.infradead.org/mailman/listinfo/get_iplayer
