After some time testing along with Justin P (providing, as usual, a generous amount of his time), a lot has been ruled out as the culprit/confirmed as to not contribute (e.g., aforementioned resampling), but no clear cause. Neither of us has so far found a way to generate a file set (all songs as individual files) where song 2 or 3 (as shown above) does not have the tick introduced into the file at the end (track 2) /beginning (track 3). In my mind, this is the crux of the issue - ticks should not be introduced into individual tracks upon render with a splice.
Here’s an interesting (at least to me) finding:
If rendering the album as a single file, ticks do not get introduced, even if that render is entirely from individual wavs that have the ticks in them at the individual track file starts/ends!
At the risk of sounding like being on a loop, it’s ONLY when rendering into individual tracks that the ticks appear.
Hopefully that furthers the info provided in my earlier posts in getting to the bottom of this. Thankfully the client has some flexibility in the release date, but I still hope to resolve this soon. It’s the nicest clients you want to give the highest level of service possible, and then some.
Yeah. What’s perplexing is that if you zoom way in on the start of one of the rendered files, you can see something.
But if you line these rendered files up back to back in a montage, and play from one to the other, I don’t hear a tick.
And even weirder is if you render a NEW full WAV from these questionable WAVs, there doesn’t appear to be any little noise! So weird.
Attached are two screen shots. One is where you can see something at the very start of the file, and the other is of the NEW full render and you would expect to see that same thing at 5:20 but it’s not there visually, or audibly.
Whatever this is, I wonder if it’s small enough that most pro apps don’t have a problem, but consumer apps like iTunes may produce more of a tick at this transition point. I’ve long since trusted iTunes for perfect gapless playback so I’m not ready to consider it gospel at this time.
I made a 100 Hz sine wave in a 48K file, put that in a montage and randomly added splice markers. Then rendered through the master section with src to 44.1 cd tracks. At two of the track points I got abberations. The other track points were clean. I can’t hear the ticks, but the Izotope picture looks pretty similar to what kywoman posted earlier.
To help prevent issues, I never run the Resampler on renders, I like to externally SRC and use the Custom Montage Duplicate option so I can’t speak to cases where Resampler might be causing an issue.
I still believe that with my workflow, the renders are OK. I don’t hear an issue when loading the WAVs of each track into a new montage and playing through the transitions. And if I render a new full WAV from the rendered WAVs of each track (as a dummy check), I still don’t hear any issues at the transitions, and those visual concerns at the start/end of files in a spectrogram (RX or WL in orange mode) are not there.
PG did tell me this:
To make it short:
any discontinuity in the audio will cause a discontinuity in the spectrogram.
The start of a file, is a discontinuity between silence and sound.
A couple years ago I remember doing some tests and research and I found iTunes to not be trustworthy to play back gapless WAV files and all bets are off with mp3 and AAC due to the few milliseconds of silence that pads the start of each file.
What I currently think kywoman is experiencing is two non issues:
iTunes can’t be trusted for gapless WAV playback
And PG’s comment about the discontinuity in the spectrogram.
For project approval, I send clients a DDP w/HOFA DPP Player, and sometimes WAVs of each track so they know where the tracks start, and a reference mp3 of the whole thing as one file to approve the track spacing if the DDP is too hard for them to use. I think this method works for exposing problems, but loading WAVs into iTunes (or any consumer media player) is likely to produce user/software indued errors that aren’t really there.
I’m currently going with, if the WAVs sound correct when played back in a new montage to test, and also sound/look correct when rendering a new full test file to inspect, then all is good.
We of course still need to be careful when creating gapless albums but I think my method is capable of that.
I just mastered a 4 CD set for Rhino/Warner and 3 of the 4 disc had some gapless tracks and the WAVs passed their stringent QC department who are more diligent than I would have expected, and that’s a good thing.
SRC has been ruled out as a causal agent. It happens with or without SRC at any point.[/quote]
Single continuous files don’t get the tick - I’ve confirmed and maintained that from the outset with said workflow. What would you do differently on this project for rendering all the songs as a file set?
Yup, having that sine wav shown above cut to zero at end of 2, or jump up from zero at beginning (3), as on individually sliced files, is where the issue arises, and why the click appears on the files in a spectral view.
It makes sense to me that when playing the tracks back to back in Wavelab, and indeed, when rendered as a single composite of all tracks, there’s no click, because there’s no discontinuity there, as shown in the above pic at the sample level - the waves are cresting, but it’s just a regular old sine wave with no space between the samples/tracks.
When playing back the individual files forming a new montage, WL seems to be able to ignore the discontinuity introduced at beg.end of files. But no other app will do the same. To wit…
As discussed, it also happens in VLC. Maybe iTunes is untrustworthy for a variety of other reasons, but if invoking that conclusion as the culprit here, then it should follow that VLC or Reaper can’t be trusted either! And I think we can both agree that Reaper is a pretty pro app. Put tracks 2 and 3 in a track on Reaper and play back the session - a loud pop!
But you see the ticks! And you hear them! That is problematic.
I don’t see how one goes about explaining this to a client - from your statement, it seems I’d have to advise them to not play the files in iTunes or VLC, or anything else that will accurately read the tick that is at the beginning of a file? That they can’t play an individual song in these apps without getting a loud pop? Or even play all the files back to back continuously without getting the pop?
Whether we like iTunes or not for other issues is immaterial to this issue, as the issue happens in playback of the files, either at start of the file or through the section of the two files (towards end of track 2, seamlessly playing into track 3) in both VLC and Reaper. And even if iTunes had issues, it’s still a dominant playback format that should be considered for end-users. They are going to use it whether we prefer them to or not.
I love me some Rhino! This tick introduction is a very infrequent occurrence for myself. I’ve rendered hundreds of live shows with individual tracks. But it doesn’t mean that when it occurs, it should be disregarded. I agree your method is capable of that. A number of workflows are. But what’s interesting here is that your workflow was used here! I’m not trying to attack it, I love it. I’m wanting WL to better address these issues, however infrequent they occur.
I really hope there will be some other options / tools for these scenarios. And by that I mean the Feature Request of expansion of the find zero crossing feature, and other tools that would allow people to better address discontinuites at CD Splices, ideally even before QC’ing! Maybe like the CD Conformity check, as an example.
I have to run for today, and maybe there are some ways I could have worded the above bits slightly softer. Here’s my disclaimer: with all of the above, I can’t stress enough that I am not trying to be snarky or combative. I’m just trying to drill down on the problem. I have nothing but respect for y’all helping out. It never hurts to keep at the forefront there’s a big difference between disagreeing with an argument (premises and conclusion) vs. the person!
Yes, I’m aware that sample rate change during render isn’t a factor but I put that in there more for Bob99. Because I prefer the sound of RX or Saracon, and I want to rule out the chance of anything going wrong on gapless renders, I never take a chance with SRC running live even though it seems neutral in this case.
I just took some real-life gapless WAVs of a continuous jazz album that I mastered and tested them out. In iTunes, one of the transitions did indeed have a glitch, but not all of them. Most were OK.
Then I tested in J River Media Center which I trust more than VLC or iTunes. I’m not anti-Apple or iTunes, but I don’t use it for QC work.
In J River Media Center which I consider a more prosumer media player, there were no glitches between tracks. I made sure it was set to “gapless” mode and not doing any crossfading.
Then I loaded the WAVs into a new REAPER session and ensured there was no space between the items, or auto-crossfades. Just butted up back to back like in a WaveLab montage test session.
Again, in REAPER, I didn’t get any pops when playing from one item to the next.
I think we’re talking past each other a bit here on some points so I have to stop investing time right now but I think for the most part, the situation is safe.
The bottom line is if you render the files you intend to use for distribution, and then put them in a new montage to test, and don’t hear an issue in the new montage on playback, or if you render again a full file to simulate gapless listening and there are no ticks, then I think there are really no ticks and it’s the best you can do.
Attached are two screen shots (close and far) of one of the transitions shown in REAPER.
kywoman I’m confused. Are you saying that in your renders the last sample and first sample are at 0 ? That’s not what I get in Wavelab 9 even with SRC (I know src is not an issue with you, but that’s the only way I’ve been able to get this “tick” to happen with wav files). Could you post a screen shot of the renders butted together in a Wavelab montage showing the last sample of the outgoing track and first sample of the incoming track in waveform view?
This was my screenshot of the renders doing that in Wavelab 9.5 with SRC. The samples aren’t perfectly correct, but the first and last samples are not at 0.
However I did the same thing in Wavelab 8.5 with crystal SRC and I do get the incoming first sample at 0 (which is totally wrong), and it definitely ticks.
Are your renders actually showing the first or last sample at 0, like that 8.5 pic ?
I think it’s important to differentiate between running playback from silence into a file whose first sample is not at 0 vs. having the first sample in the file actually being at 0, like in the 8.5 pic.
I still get the pop introduced when rendering individual tracks from this new file.
The problem is not a bug but a side effect of audio processing. That is, when a clip is rendered individually, the DMG filter is starting from a discontinuity point, ie. from “no audio” to “audio”. But this plugin has latency, which means it needs previous samples to work optimally, that is to produce sample T it needs to know samples T-1, T-2, T-…
When you render the file as a whole, no problem.
When you use this kind of plugin, the only way to have a no click production, is to render the whole montage and then do the split, when there is no more a plugin involved.
It’s on my todo list in the future, to have WaveLab does it automatically like this: when rendering a single clip, WaveLab would start to render eg. 2 seconds before the clip, but would then discard the 2 first seconds of samples in the resulting file.
Thanks for the info. Yes, because of this, I always render the whole montage first as one long file to accurately lock in all the plugin processing, and kywoman is doing this as well. It’s the only way I know of right now to safely avoid glitches when eventually rendering a WAV of each track without any FX running live.
The problem is that even with this workflow, kywoman appears to eventually be getting WAVs that are not seamless when rendering a WAV of each track with no effects or SRC happening.
I’ve been testing my recent seamless WAV master files and while I do see something in the first 10ms in a spectral view, I do not hear any ticks or pops when I line the files up back to back in a montage, in REAPER, or listen in J River Media Center to test them out.
It’s listening in iTunes and VLC that has triggered kywoman’s concern about the WAVs having a tick when playing from one song to the next (instead of a smooth transition that was in WaveLab) but I personally do not trust iTunes to playback perfectly anymore. It used to. I tested my WAVs in iTunes and some transitions were fine, some not, and my previous tests have produced erratic results when repeated, meaning not the same each time.
I have even rendered a new test WAV of the full project using the rendered WAVs of each track to better analyze those transition points and the new test render doesn’t reveal any ticks or pops at the transition point which is good.
Anyway, wondering if PG can comment on the state of rendering seamless WAV files when no FX are involved similar to my workflow. I actually run a dither live in the montage output and that doesn’t cause a problem. It seems to be more CPU heavy plugins that cause this.
Yes PG, but from my understanding kywoman is getting this with no plugins, no processing, no SRC. I thought that’s what Justin confirmed from the files and montages he got.
I’m still ruling out iTunes as a usable test platform. And here’s why:
An album I mastered recently just came out today and I was reminded how much it tested my gapless master practices. Every song segues into the next, it’s meant to be a montage of listening to AM radio in the middle of the night while driving. Very creative album.
Here is the link for reference to what I’m about to say below:
Anyway, I remember meticulously inspecting all the master formats to verify no issues between tracks with the master WAVs. The DDP was of course OK too. Nearly every song overlaps in a fairly music section so this is a great test case.
I just checked the album on Apple Music via my phone, streaming from 4G, as well as Apple Music, Spotify, and TIDAL on my studio Mac connected to Internet. All the transitions are perfectly in tact. No clicks, no ticks, nothing. Just smooth transitions.
Then, I took the master WAVs that I provided to the client and played them in iTunes. Then there were problems.
But, the problems were not repeatable. Some transitions were OK, some were not, and some of the big ones went away or sounded different upon repeated playbacks. This confirms that iTunes is not great at playing gapless local WAV files which may seem surprising but I believe it to be true.
J River Media Center has played eveything I’ve tested perfectly as expected time after time.
So what I think kywoman is experiencing is iTunes induced glitches, and the fact that the starts of each file show something at the start/end in the spectrogram is causing kywoman to think there is a problem with the files which I can understand, but from what I understand, is normal. I’m tempted to chop some files in Pro Tools, export them, and see how the first 10ms looks in a spectrogram.
But I still feel confident that with my workflow that kywoman seems to be mirroring, there is no problem with the actual files and trying to make them behave in iTunes is a losing battle.
NO! I apologize, I definitely misspoke there. For the rendered tracks, the sine wav never cuts to zero or jump up from zero at the file edge. The waves start/end from/at non-zero values, there’s no pull to 0 at end. The two screenshots I posted a few posts ago are correct, the bright orange ticks, and the wave crests in WL at sample level are the file edges. Sorry for the confusion there.
Exactly, bob99 is right. I experience this without no plugins, no processing, no SRC. My initial discovery was from a montage that came from a montage that had the DMG. BUT, I just made a new copy of that original montage with Limitless, and deleted that plugin, the only plugin. So it’s a file directly from Reaper with markers converted to Splice Markers. I render tracks (wavs) at native SRC and native bit (48k/32F) no dither, no master section on. And the ticks are still introduced exactly like before. I tested at 44/16 as well. Therefore, I don’t think Limitless (or any plugin) is the culprit for the ticks being introduced here, as the tick is introduced without any of the audio processing PG mentions.
OK, for the purposes of getting to the bottom of the tick, let’s agree iTunes is flawed. Whether it’s flawed or not, it’s mostly a digression. Though important to note, I was in no way trying to talk past you. I really wanted to know how you would address this if this happened with one of your clients. But this was all a side topic, and I don’t think it helps identify the cause to of the tick to spend much more time on iTunes.
The issue is that WL introduces a tick into CD Tracks. This is a fact - the tick is not there on the continuous file used to create the individual files, and then it appears after individual files after rendered, without any processing otherwise. The evidence is clearly shown, and it can be clearly heard. You confirmed this, and that’s why I was genuinely confused and replied with “but you heard the click, and you see it (the loud value in a spectral view).” So given this tick is written into the files, how can one conclude there’s “no problem with the actual files.”
If I’m understanding correctly, the supporting evidence you’re using to this claim, your own sessions and test tones, or involving iTunes, are secondary or even tertiary points. Why not place the individual tracks 2/3 from the problematic session I supplied to you in Reaper and J River? The whole purpose of my supplying the continuous wav and .mon was so you, a senior user, could confirm the issue yourself and have greater ability to test, offer insight, or further describe the issue to PG and others so that we can prevent the issue recurring to any user, however infrequent. I’ve already said this is a very infrequent problem, and that I’ve rendered individual tracks from concerts and other sources that have constant audio running through them for entire program/album. I’ve done this a lot of times without incident. For this issue, there’d be little point in me supplying examples of all the times it goes off without a hitch. The session I provided does indeed create the issue, so I don’t see why that’s not considered in your testing, and in concluding there’s no problem with the actual files. To not do so is indeed talking past another.
I don’t think WaveLab is putting ticks at the starts of files. I don’t hear them in any rendered files when tested in REAPER, J River, or a new WaveLab montage. Only iTunes, but not in a repeatable manner.
What can be seen in the spectral editor at the starts and ends of files, also appears when exporting clips from Pro Tools. I don’t think it’s a WaveLab problem, or problem at all. I think it’s a function of how the display works.
I will test your transition from 2 to 3 again in REAPER and J River, and perhaps render a new file of that transition to disclose if there is indeed a problem with the files, or if the problem is the player.
That would be great PG. I don’t render from continuous audio to regions/tracks with processing/plugins except dither, but that should take care of any issues with doing it with plugins or processing I would think.
I just tested some files from kywoman that were rendered correctly from WaveLab (by kywoman), by putting them in REAPER on a single track, lined up back to back with no space (or crossfades) as they should be, and there are no ticks or glitches between the files/tracks when played back. It’s perfectly seamless, in my opinion. I then rendered a full WAV of this as proof that there are no issues.
Can we agree that if the files are lined up back to back (as they will be presented to the streaming services) in any software, and there isn’t a tick at the end or start of the files, then there isn’t really a tick there?
A full render of this mock up should put an end to it I would assume right?
This reminded me of an old post from the JRiver forum about how iTunes deals with gapless (lossy but most likely lossless also).
It goes from file header information, but It also learns, and adjusts, and keeps adjusting if it finds it’s not quite correct, and it saves that per song gapless information in that particular player library.
That’s why it’s changing. It’s actually one of the more sophisticated gapless systems because of that the JRiver post surmised.
I’ll dig that up and post a link. ymmv but I’ve had JRiver do worse than iTunes in a lot of cases.
