Music Converter adding samples to converted file

[Treelady]

I recently converted 24-bit 96kHz WAVs to 16-bit 44.1kHz from a live album. The album is one continuous wav. The track markers are there so users can skip on a CD or add individual songs to playlists on streaming platforms. However, the resulting 16/44s have extra samples of silence appended at the end of the file. Thus, they can not be butted against one another to for seamless playback.

Is there a reason this is happening? Is there anything I can do on my end to prevent it? I did the same conversions in three other applications, none of them added extra samples.

Spoon, if you want to PM me, I'll provide more details so as to not bore people here. I suspect there could be a problem with the parameters as I selected them, unless there is some reason the math has to resolve this way.

Thank you in advance.

[Spoon]

How many samples?

The conversion from 96KHz to 44KHz is not 1:1 in sampling, there will always be a slight difference, I would expect < 20 samples though

[GBrown]

I recently converted 24-bit 96kHz WAVs to 16-bit 44.1kHz from a live album. The album is one continuous wav. The track markers are there so users can skip on a CD or add individual songs to playlists on streaming platforms. However, the resulting 16/44s have extra samples of silence appended at the end of the file. Thus, they can not be butted against one another to for seamless playback.

What if you tried converting to 16/48k? Keep the sample rate in the same lineage.

[Treelady]

What if you tried converting to 16/48k? Keep the sample rate in the same lineage.

Forgive me. I don't understand the question. Why would I choose to do that?

[Treelady]

How many samples?

The conversion from 96KHz to 44KHz is not 1:1 in sampling, there will always be a slight difference, I would expect < 20 samples though

Sorry, Spoon <20 samples? Really? Music Converter is traditionally PERFECT. As in PERFECT. Don't be modest. This application is superb and almost always matches to the penny.

But I think I found the source:

Here is some more interesting information.

In all graphics, the output of Music Converter is in the upper lane. The source is in the lower lane.

A crucial bit of information: all of my conversions include a VST3 plug-in at the end of the chain. And it MUST be the VST part of the job that is causing this problem.

Comparing the original 24-bit 96kHz source against a version where Music Converter simply 'converts' the file to 24-bit 96kHz (but adds a brickwall limiter with a gain of +0.0 and a ceiling of -0.3db FS) the files are different in several key ways.

• 5.704 samples are added to the beginning of the output file.
• 5.704 samples are deleted from the output file - that audio content is gone!

Start of file. The top, which represents the output, is padded with almost six samples that shouldn't be there.

End of file when aligned against true content. Note audio content is deleted entirely. (Not the second track "Hide and Seek" is not accidentally positioned to cover the track on the left, the first track "Hell In The Hallway" Ends exactly where the waveform ends, and the second track matches at the start where it aligns in this screenshot).

Here is what happens when I run the same job to convert the 24-bit 96kHz file to 24-bit 96kHz. Spoiler Alert - the conversion is correct.

[GBrown]

Forgive me. I don't understand the question. Why would I choose to do that?

For the same reason you chose to convert to 16/44.1. Why did you choose that particular bit depth and sample rate?

There are two common paths for audio. The Redbook CD standard uses 16-bit / 44.1kHz samples for reasons they chose back in the early stages of digital music. This lineage is the background for 44.1>88.2>176.4>352.8 as the technology evolved (doubling each time). More modern music is based on a more binary friendly 48kHz sampling, so the idea of 48>96>192>384>768 and beyond applies.

Moving backwards down the line to compress the size of your 24/96 file is a more natural downsample to 48kHz. The file size difference between 44.1 and 48 is not that significant. But these additional blocks you are getting are probably partly due to the mismatched conversion.

Keep in mind you are making two conversion here. Not just the rate from 96kHz to whichever you choose. But also in the bit depth in going from 24-bit to 16-bit. Both conversions introduce a quality drop from your original file.

[Treelady]

Here is what the source audio looks like. The files start and end at a zero crossing

[Treelady]

Finally, I did the same conversions using other SRC titles that allow a VST Plug in at the end of the conversion routine. They all completed the calculations correctly. The output files line up exactly as desired. (Although one great-sounding title added samples to the end of each file, but not the beginning). So I don't think the plug-in itself is doing something with respect to the samples.

[Spoon]

Noted

[Treelady]

For the same reason you chose to convert to 16/44.1. Why did you choose that particular bit depth and sample rate?

I didn't choose the rates.

• The Label and Producer specified gapless playback (regardless of PCM format)
• Sony Phillips chose the rate 16-bit 44.1kHz when they specified the CD standard, which is the required rate for a DDP production set.
• The Label per the Vinyl Plant specified 24-bit 96kHz pre-masters
• The Label per the common streaming platforms (Spotify, Pandora, et al.) specified individual 16-bit 44.1kHz files for aggregation
• Apple specified 24-bit 44.1kHz OR 24-bit 48kHz for Apple Digital
• Tidal will accept 24-bit 96kHz
• The Video House specified 24-bit 48kHz
• The Video / Broadcast / Movie streamers specified multiple submission standards depending on their adoption of EU R128, ITU-R B.S.1770-4, AES Streaming, CALM, Atmos (pre render), THX and others that have kept me busier generating parts than the actual mastering aspect of the project. Most stipulate 48kHz, but not all.

Moving backwards down the line to compress the size of your 24/96 file is a more natural downsample to 48kHz. The file size difference between 44.1 and 48 is not that significant. But these additional blocks you are getting are probably partly due to the mismatched conversion.

The integer conversion “lineage” you mention appears to be built on a fallacy that you can toss every other sample when going from 96 to 48 (decimation), but that’s not how it works. (And even if it was, converting to a common integer rate is the most popular method). Even then, we can’t toss samples. Going from 48 kHz to 96 kHz, has an immediate concern that 48 kHz cannot encode any frequencies above 24 kHz. Consequently, the source must pass through a process to remove content above that limit before we begin eschewing data. This stage involves the proprietary application of antialiasing and anti-imaging filters. How this is implemented is as much art as science. (And it’s why different conversion routines sound different and why designers keep their methods close to the vest). After this task is complete, decimation can commence.

One disadvantage of any filter (FIR or IIR) is the possibility of adding samples. FIR filters can add samples to the end, while IIR can add samples to both the top and tail of a file. Some titles I use produce an ‘exact’ match with the output file, but I suspect they are merely truncating their results to appear clever. But I could be wrong.) Since both integer (lineage) and non-integer (non-lineage) conversions require filtering, additional samples are always possible.

Ultimately, the sound quality of 96 to 48 vs going 96 to 44, depends on the superiority of the algorithms. We can achieve the same sound quality in the frequency domain (images and aliasing artifacts living beneath the quantization noise floor) for either, provided we're willing to pay with a higher CPU load on the non-integer jobs.

Keep in mind you are making two conversion here. Not just the rate from 96kHz to whichever you choose. But also in the bit depth in going from 24-bit to 16-bit. Both conversions introduce a quality drop from your original file.

I can replicate the issue on any sample rate and even pass through 24/96 to 24/96. The culprit, in my specific case, is the VST, but I appreciate your concern.

[PeterP]

Problem with our VST adapter acknowledged and confirmed, will be addressed shortly.

Meanwhile, I am having trouble understanding why you're not resampling the whole album in one pass, as one stream, then cutting tracks.

Even with 100% confidence in your software doing the right thing, the resampler (and probably other things in your chain) operates on block basis and will be fed made up data at the end of each track to produce a complete block, then the made up data will be trimmed from the output. While I'm not aware of any killer samples that glitch audibly with our current code, you simply do not want this if mastering audio meant to play continuously.

Finally, you're going to be recutting the downsampled output anyway for Audio CD with 588 sample block alignment, but you must be well aware of that.

[Treelady]

It was related to the film sync, and I think the post-house separated them before I got the sources. I pitched the "one giant wave" idea as that's what every other music 'film' and live concerts ask for. And they could divide them however they wanted. But they said splitting the single file did something to their timeline. (?????) The more I asked for an explanation, the less I got, so I quit trying. It was obvious that I poking a hornet's nest.

You guys need to realize that I have to deliver whatever they say at my point in the production chain. Heck, earlier in the year, someone demanded 16-bit 192kHz masters..... so when someone tells me something preposterous about why they can't do something straightforward without some strange output from me, I no longer argue about it.

And I'm sorry about the VST adapter. That's a pain in the ##$. I didn't mean to contribute to headaches.

[Treelady]

Meanwhile, I am having trouble understanding why you're not resampling the whole album in one pass, as one stream, then cutting tracks.

I just ran tests exporting from 24-bit 96kHz to 16-bit 44.1kHz, then opening a new session, loading the 16/44's, and butting them next to one another, and it works perfectly on

• Sequoia 17
• WaveLab Pro 10.5
• Nuendo 12

I did not have time to check with Pro Tools or Pyramix, but friends who work on those platforms were confused as to why I was even asking the question. They don't convert then slice, either.

Also, in checking best practices among post and the large streamers, they want the sessions exported directly from the source to the destination sample rate. There is no converting then slicing. (The odds of a problem happening with the cuts/slices being off from the original program is high. There is no way I would want a human to do that. Something will be wrong).

At this point, I'll say respectfully that I couldn't pretend to do the math and coding and design choices you make in bringing this software to the public.

But it's clear that the applied uses of these tools in a production context are not something you deal with on a day-to-day basis. I'm sure I'm missing the actual 'why' we don't convert and then slice the audio, but all of the film people I've emailed said that's a big NO. I don't know if it's 'because we always did it that way." Or if there is a specific reason (loss of precision related to time code of some kind???), but that's what I'm being told by colleagues in industry.

Thank you for all of the help on this. I challenge any other software maker to be as responsive as dbpoweramp! You guys are fabulous.