[FFmpeg-user] File metadata in m4a causing player problem?
I have a set of m4a audio files which I can play but on which the progress bar does not work. If I select anywhere along the progress bar playing starts again from the beginning. The only difference I can see when using ffprobe to examine the metadata is that files which have a creation_time set have a non functioning progress bar problem. Files which do NOT have the Stream metadata :creation_time, play correctly. The metadata is shown:- Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 319 kb/s (default) Metadata: creation_time : 1970-01-01T00:00:00.00Z handler_name: SoundHandler This creation_time seems to me like a default not the actual time when file was created and may be the cause of the player problem. What I wish to do is remove the tag: creation_time : 1970-01-01T00:00:00.00Z I confess using ffmpeg to achieve this, if indeed this is the correct tool, is well beyond my ability and I am seeking help here. I appreciate this still may not fix my problem but I must try and eliminate possible causes and this is one possible fix. Can anybody help please. Budgie ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] File metadata in m4a causing player problem?
Hi Budgie, On Sun, Oct 20, 2019 at 09:56:40 +0100, Budge wrote: > I have a set of m4a audio files which I can play but on which the > progress bar does not work. If I select anywhere along the progress bar > playing starts again from the beginning. In which players does seeking not work? In all of them? Which did you test? How were there files created? Are they arbitrary files, or did you create them with ffmpeg? Can you provide some of these files? > The only difference I can see when using ffprobe to examine the metadata > is that files which have a creation_time set have a non functioning > progress bar problem. That may be a symptom of their creation, but not the actual root cause for your issues. > What I wish to do is remove the tag: > creation_time : 1970-01-01T00:00:00.00Z ffmpeg certainly didn't create this by itself, but I understand that's not what you're trying to say. ;-) > I confess using ffmpeg to achieve this, if indeed this is the correct > tool, is well beyond my ability and I am seeking help here. Even though I don't believe that is the root cause, I was going to explain to you how to strip metadata using ffmpeg. But it turns out that, when remuxing, ffmpeg doesn't actually copy the creation_time. So all you have to do may be: $ ffmpeg -i input.m4a -c copy output.m4a You can then test the output file. The resulting file may also be fixed for other reasons than the metadata, e.g. reconstruction of some index or something like that, which the original may be missing. (Guessing here - just go try.) Hope this helps, Moritz ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] File metadata in m4a causing player problem?
On 21/10/2019 09:28, Moritz Barsnick wrote: > Hi Budgie, > > On Sun, Oct 20, 2019 at 09:56:40 +0100, Budge wrote: >> I have a set of m4a audio files which I can play but on which the >> progress bar does not work. If I select anywhere along the progress bar >> playing starts again from the beginning. > > In which players does seeking not work? In all of them? Which did you > test? > > How were there files created? Are they arbitrary files, or did you > create them with ffmpeg? > > Can you provide some of these files? > >> The only difference I can see when using ffprobe to examine the metadata >> is that files which have a creation_time set have a non functioning >> progress bar problem. > > That may be a symptom of their creation, but not the actual root cause > for your issues. > >> What I wish to do is remove the tag: >> creation_time : 1970-01-01T00:00:00.00Z > > ffmpeg certainly didn't create this by itself, but I understand that's > not what you're trying to say. ;-) > >> I confess using ffmpeg to achieve this, if indeed this is the correct >> tool, is well beyond my ability and I am seeking help here. > > Even though I don't believe that is the root cause, I was going to explain > to you how to strip metadata using ffmpeg. But it turns out that, when > remuxing, ffmpeg doesn't actually copy the creation_time. So all you > have to do may be: > > $ ffmpeg -i input.m4a -c copy output.m4a > > You can then test the output file. > > The resulting file may also be fixed for other reasons than the > metadata, e.g. reconstruction of some index or something like that, > which the original may be missing. (Guessing here - just go try.) > > Hope this helps, > Moritz > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". > Hi and very many thanks for the detailed reply. I obtained the file from BBC using get_iplayer, one of several and years ago. I believe the problem resulted from my poor workmanship when, while upgrading my workstation, I failed to install AtomicParsley. (Running on 64 bit system with openSUSE but cannot recall version.) As a result the files would not play on the Linn DS until I moved the moov atom to the start of the file metadata using qt-faststart but otherwise I believe the tags were intact. The files then played OK but the progress bar problem was present. I can let you have samples of good and bad files for comparison but they are quite big so need your advice how to get them to you. I can use Dropbox and send a link if this would be OK. The problem only occurs with my Linn DS devices. I am using BubbleDS on Samsung S6 Android phone as control point and minimserver on Qnap NAS as media server. On another player such as a RaspberryPi with Raspbian OS and IQaudio PiDAC etc and Upmpdcli the progress bar works as it should. AFAIK get_iplayer uses ffmpeg when downloading but I am not a coder so cannot comment further. In the light of your advice above there may be other criteria to examine in the file as; None of the files I have which do NOT have the creation_time tag work perfectly. Only those files which still have the creation_time tag have a problem with the Linn DS devices. Meanwhile I will try your suggestion and report progress. Many thanks once more. Regards, Budge ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] File metadata in m4a causing player problem?
On 22/10/2019 16:57, Budge wrote: > On 21/10/2019 09:28, Moritz Barsnick wrote: >> Hi Budgie, >> >> On Sun, Oct 20, 2019 at 09:56:40 +0100, Budge wrote: >>> I have a set of m4a audio files which I can play but on which the >>> progress bar does not work. If I select anywhere along the progress bar >>> playing starts again from the beginning. >> >> In which players does seeking not work? In all of them? Which did you >> test? >> >> How were there files created? Are they arbitrary files, or did you >> create them with ffmpeg? >> >> Can you provide some of these files? >> >>> The only difference I can see when using ffprobe to examine the metadata >>> is that files which have a creation_time set have a non functioning >>> progress bar problem. >> >> That may be a symptom of their creation, but not the actual root cause >> for your issues. >> >>> What I wish to do is remove the tag: >>> creation_time : 1970-01-01T00:00:00.00Z >> >> ffmpeg certainly didn't create this by itself, but I understand that's >> not what you're trying to say. ;-) >> >>> I confess using ffmpeg to achieve this, if indeed this is the correct >>> tool, is well beyond my ability and I am seeking help here. >> >> Even though I don't believe that is the root cause, I was going to explain >> to you how to strip metadata using ffmpeg. But it turns out that, when >> remuxing, ffmpeg doesn't actually copy the creation_time. So all you >> have to do may be: >> >> $ ffmpeg -i input.m4a -c copy output.m4a >> >> You can then test the output file. >> >> The resulting file may also be fixed for other reasons than the >> metadata, e.g. reconstruction of some index or something like that, >> which the original may be missing. (Guessing here - just go try.) >> >> Hope this helps, >> Moritz >> ___ >> ffmpeg-user mailing list >> ffmpeg-user@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-user >> >> To unsubscribe, visit link above, or email >> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". >> > Hi and very many thanks for the detailed reply. > > I obtained the file from BBC using get_iplayer, one of several and years > ago. I believe the problem resulted from my poor workmanship when, while > upgrading my workstation, I failed to install AtomicParsley. (Running > on 64 bit system with openSUSE but cannot recall version.) > > As a result the files would not play on the Linn DS until I moved the > moov atom to the start of the file metadata using qt-faststart but > otherwise I believe the tags were intact. The files then played OK but > the progress bar problem was present. > > I can let you have samples of good and bad files for comparison but they > are quite big so need your advice how to get them to you. I can use > Dropbox and send a link if this would be OK. > > The problem only occurs with my Linn DS devices. I am using BubbleDS on > Samsung S6 Android phone as control point and minimserver on Qnap NAS as > media server. > > On another player such as a RaspberryPi with Raspbian OS > and IQaudio PiDAC etc and Upmpdcli the progress bar works as it should. > > AFAIK get_iplayer uses ffmpeg when downloading but I am not a coder so > cannot comment further. > > In the light of your advice above there may be other criteria to examine > in the file as; > > None of the files I have which do NOT have the creation_time tag work > perfectly. > > Only those files which still have the creation_time tag have a problem with > the Linn DS devices. > > Meanwhile I will try your suggestion and report progress. > > Many thanks once more. > Regards, > Budge > > > > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". > Just a follow up trying to run file through ffmpeg as you suggested the file now does not play and BubbleDS moves to next file in playlist or stalls. If you have time I would appreciate your examination of the samples. Let me know. Regards, Budge ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] File metadata in m4a causing player problem?
> If you have time I would appreciate your examination of the samples. Could you post the dropbox link? ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
