So the reading software, unaware that the useful data has finished, needs to fill the empty space in the last 'block' - it would be entirely normal for it to dump something into that space. The writing software must put an 'end of data' flag after the last packet - but it is not doing that. His explanation was that the end of audio data packets does not necessarily coincide with end of a data 'block'. I took the issue to an engineer I often use - he is of many years experience in broadcast matters and is now operational senior engineer with the national transmitter authority. I doubt it but perhaps the conversation was older than that - I'll check later. Strangely a search of all my posts in the past 3 months does not reveal those posts. I had a lengthy forum discussion on this matter with within the last couple of months. To any and all - please feel free to email me directly whenever you run into issues with any of the ClipToolz apps.Īll audio trancodes that I have tried display the problem, including transcoding to. If you can provide a little more detail I'm happy to investigate and do whatever I can to provide a fix. What format and resolution are your source clips - AVCHD, ProRes, 1080P, 4K, etc?Īlso, do converted clips, when played in VLC or other players, have the same audio problems (outside of importing into LW)? Are all conversions of all sources - and to all codecs - producing audio problems, or only H.264 conversions that are troublesome? I can tell you that ffmpeg AAC support is poor - if it is the culprit I can change to an alternative audio format if it will make the difference. I'm always happy to provide fixes or investigate issues with my applications if I receive notice of those problems via email to Any and all feedback is welcome!įor the sake of this discussion though I would ask for some clarity. I'll see if I can locate it and post a copy or - I do not monitor forums regularly - and have also not had any direct reports of audio issues. Some time ago I posted the so far most plausible explanation of why this happens, courtesy of an engineer I use in such matters. I am astonished by two things, that Cliptoolz has not been able to remedy the issue (Eyeframe is a legacy product no longer under development) and that both of these with a known problem are so enthusiastically and uncritically endorsed by this forum.Īs part of much testing I have also found that transcoding in Quicktime Pro and Lightworks does not produce the glitch and that 'washing' a sound file in the free Sound Devices Wave Agent Beta removes the glitch added by the other two. VideoGo does not have all the codec and timecode support of the others. Further if one process a file made by either of the above problem front ends it also removes the 'glitch'. There is another ffmpeg front end transcoder, iDealshare VideoGo, while not free and I needed to buy a licence to check, in limited testing it does not produce the same sound 'glitch'. In extensive testing I have found that the pop at the end of sound is always present when material is transcoded in either Eyeframe or Cliptoolz both of which are front ends for either/or ffmpeg or ffmbc.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |