Jump to content

TomH

Members
  • Posts

    37
  • Joined

  • Last visited

TomH's Achievements

Member

Member (3/7)

0

Reputation

  1. This topic seems to be related to the issue I've encountered. I cannot say whether the audio has shifted relative to the picture but transitions are affected. The audio transition at the Fade through black transitions is thrown off by exporting to H264 high quality .mp4 at 30fps FIXED but is okay at the Variable Frame Rates I've tried (SmartMax to ~45 and max 30). I'm on VPP 8.45. It's as though the audio track has been advanced relative to the fade so you hear a switch to the second audio before the video transition.
  2. Great! We're on the same page and your hearing is just fine where it matters! I assume your initial observations were clouded by that mysterious behaviour when playing through an Internet browser. According to MediaInfo, the "H264" and "MPEG:4" labelled MP4 exports use the identical AAC-LC codec but the so-called 192kbps is 166kbps for MPEG.
  3. Don't listen to them directly from OneDrive online; that adds a layer of confusion. Having just now done so with Edge, I was taken aback and agree that the difference is subtle when heard that way; the quality was disturbing in both. When the files are local and played through the Windows 10 Films & TV app, the difference is enough that I detect it with laptop speakers and find it objectionable with headphones. I downloaded the MPEG and confirmed that the file played cleanly, locally, but something had changed when played online. So I tried Firefox: the MPEG started off with the flutter distortion but within a few seconds it cleared up and stayed that way on repeated plays back and forth between H264 and MPEG. Back to Edge, and MPEG cleaned up within a couple of seconds. But back and forth between H264 and MPEG tends to degrade the MPEG while the local file plays clean; same with Chrome. So maybe there is some issue with caching in the browser or Internet which results in the data being mixed up - I know that sounds crazy but better to avoid the possibility of confounding the A-B comparison with one more source of error. A great way to A-B them is to drop the two downloaded files into Audacity or another multi-track editor on separate tracks and loop play the first 3 seconds while soloing one then the other. If neither you nor your friend hear the hf flutter on the H264, then either both of you have hearing impairment that I don't or there is something amiss with every H264 codec in my system. In the national broadcasting company that I spent my career, that defect would have ruled out the codec for music, drama and other applications for which we wanted near CD quality. We certainly used low quality codecs for news gathering from locations where (or the era when) telephone-line modem was the only data transport channel available.
  4. Thanks, borate. I had posted a report through the website "I need technical support" option which has essentially the same form as the bug report. The bug report itself can be started outside VP using this URL https://www.nch.com.au/software/bug.html but there is no link to it on the website. Launching from VP itself fills in the product and version number on the form. I think there should be a "Report a bug" option on the website. What if VP (or any NCH product) is frozen? You can't file a bug report.
  5. I did a fair bit of close listening to audio codecs starting over 30 years ago so my hearing may be somewhat 'trained' to detect distortions. I perceive the difference between my two samples to be much worse than negligible. And there really should be none because they both use the same audio codec. If anything, the higher bitrate of the H264 audio stream should give it an advantage. What is the process of reporting a bug? What do you mean by "passed along"? Thanks again for engaging with me on my posts.
  6. I hear the distortion on your YouTube upload, same as what I ultimately published and what I hear on the VP Export. If you listen closely and do an A-B comparison between the H264 and MPEG-4 exports I referenced in Choice of video codec affects audio quality, you should hear the distortion introduced by VP's defective H264 without anything clouded by an upload to YouTube..
  7. Forking this audio discussion out of the topic 100 clip multi screen method... Manifesting as a kind of burbling or flutter in the hiss of ambient noise captured from wind in trees (I presume), the distortion was introduced in the export from VP. I have now checked more closely using just the one video clip (a long shot of a flag waving in the breeze). The VP Preview sounds the same as the original MP4 file - the hiss or wind noise is smooth across the spectrum. Exported to MP4 and it is degraded by the H264 and H265 video codecs, whether the audio bit rate is 128 or 192kbps. In MP4, VP gives no choice of audio codec - only AAC-LC is available. Surprisingly, choosing the MPEG-4 video codec results in audio quality that is indistinguishable (or nearly so) from that of the source clip. H264 AVC is supposed to be better than MPEG-4 (I know the H264 standard encompasses MPEG-4 but those are the labels VP puts on its choices) for video but it should have no effect on the audio stream when its encoder is the same. Using the Default Quality/Filesize setting in VP, here are some parameters for the resulting files: Video Compressor Filesize AudioBitRate VideoFormat H264 5.87MiB 192kb/s AVC H265 1.52MiB 192kb/s HEVC MPEG-4 4.48MiB 166kb/s MPEG-4 Visual All above set at Default Quality/FileSize, 30fps, 192kb/s It's puzzling that VP produces a larger file from the "H264" "Compressor" than from the "MPEG-4" when the former is supposed to be able to produce a much smaller file for the same picture quality or a higher video quality for a given file size. It's as though VP wants the H264 "default quality" to be much better than MPEG-4's yet I could see no discernible difference in the waving flag. And despite the MPEG-4 actual bitrate for audio being lower (according to MediaInfo), it sounds much better on the wind noise than H264. I even tried "High Quality" H264 (twice the file size) but that, too, suffers the same audio impairment. So I think there is something seriously wrong with VP's implementation of the H264 and H265 codecs and the only viable choice for MP4 format is the MPEG-4 "Compressor". P.S. The H264 and MPEG-4 exports for Default Quality/FileSize can be auditioned here
  8. The audio stream is 192kbps AAC LC so the final encoding choice should not be the issue because it is a higher rate than the preceding. Rather it is the cascading of codecs from original capture of the ambient sound by the video recorder to the playout of my finished video. We know nothing about the video recorder - its audio encoding might be linear but might be MPEG. So one can imagine that the published version has had this minimum length chain of codecs: Capture=> Export=> YouTube=> Capture (Xbox Game Bar 128kbps 48kHz AAC LC)=> VP Export (192kbps 48kHz AAC LC)=> YouTube The output of #4 sounds smooth while #5 (VP) has severe encoding artifacts. That may point to a problem with the codec used by VP or an unavoidable consequence of adding one more audio data compression codec in the chain. Sorry that we have strayed far from the subject title - is there anyway to split it out?
  9. Thanks for the feedback, Nat, including the performance aspect. This was a spur of the moment project started less than a week ago, the music not sung in 3 years and the first self-recorded videos for most of the participants. So many challenges it discouraged most of the chorus from trying. My video export takes about 3x playing time, as does building the Preview cache every time a change is made which really slows productivity. Another issue is the quality of the ambient audio in the export. It sounds ok within VP, I think, but the export exhibits the artifacts of too many audio data compression-expansion passes or excessive data compression. I've not the time to explore further and fix that.
  10. That project is just one sequence. Not to be confused with my initial test of a sequence of 2x2 sequence clips stacked in another sequence stacking them as 2x2. I'm well aware that everything in a sub-sequence is active. My version is 8.35. Is your Preview within VP of my project smooth? Thanks for trying it. Another warning of limitations being reached in my system is that a screenshot from within Preview of the sequence which has scrolling text on it did not include the text.
  11. Here's my portable project. Your observations of its performance on your hardware would be much appreciated. Mine is: Windows 10 Home 64-bit (10.0, Build 18362) Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz (4 CPUs), ~2.4GHz Intel(R) HD Graphics 520 with 128MB dedicated and 4041MB shared RAM: 8GB HDD: WDC WD10JPVX-75JC3T0 Cache Memory: 8.0 MB, 5400.0 rpm. SATA 6.0 Gb/s One strategy for speeding up the process is, where possible, to split long tracks into separate sequences, provided one can work on them independently and then assemble them in another sequence. If building a preview cache essentially takes kt, where k is some factor and t is the playing duration of the sequence, building a preview of a half-duration sequence should take approx half as long as for a full duration sequence. Tom
  12. The "hardware-accelerated video effects" option was already checked. Haven't looked into whether this laptop has the required SM2.0 hardware. I have periodically cleared "unused cache files", as much as 25GB and this just a 3-minute project. And unclear what "unused" means - unused by the current project? Disk activity is not especially high so I wonder if there is a real benefit. Better that the cached files in use be defragged, maybe. Not currently stacking sequences - that was just an experiment, a disappointing one. I've only one high-res file for the main screen. All the splits are from small files. If the project gets into bigger problems before I finish, I'll try replacing the one big file with a proxy.
  13. Nat, I wonder if your old Vista machine might be a then very good media machine with 7200rpm or faster drives, hot graphics card, etc. My contemporary i5 laptop struggles with 5 clips, and Sequence Preview becomes unusable above that. CPU utilisation seems to be the limiting factor in my case as there is plenty of free RAM and HD activity is not high. When CPU is at 100%, VP is up around 85% so, even if I could shift more to it, there's not much to be gained. And the GPU is just being tickled so the program is not taking advantage of it. As a corollary to what you describe, I had conceived of using the quad-split, initially by stacking 4 quad sequences as clips in another quad sequence and so on: 4=>16=>64 and exporting when there were signs of bogging down. However, bogging began at the start of the second level with only one quad placed inside another quad and the startling realisation that the audio track of a sequence clip, while still audible, is invisible and uncontrollable. Your method, by exporting every sequence rather than stacking, assures that the audio mix from the sequence is visible when imported to the next level.
  14. Yes, that's a layout similar to what I am doing, Nat. I have started with the split-screen grid at 5x4, planning to fill the bottom row and progress up the side columns. I found that Crop then Split adversely affects the size of the box but Scale then Split works ok.
  15. Thanks for the encouragement, Nat. I'm on the same wavelength. Plan to use a split screen grid to lay out the singers in a U, bottom based. To ensure the audio waveforms are visible, I will normalise and export each clip, cropping as needed, and bring those revised clips into the master project. I've discovered I have to scale the lyrics text to fit within the U as, almost regardless of font size, the system wants to fill the screen.
×
×
  • Create New...