Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[duclosa]

Hi all.

I've been using MC12 (12.0.404) with XP SP3 on an old Dell E1505 to play (mostly) FLAC files from NAS throug USB DAC (Audio Research) on CLASSÉ pre-amp, CLASSÉ amp to B&W speakers. Everything worked well for a number of months.

Not too long ago, I upgraded to MC14 (14.0.165) and quite a few FLAC files started playing incorrectly. Near the end of the file, there is a LOUD POP sound, just before switching to the next file. It also happens with MC15, which I tried (and bought!) this evening.

I thought that the FLAC files were somehow faulty. I opened one in WavePad, and it played correctly...

That last observation, together with the fact that MC12 plays the files correctly lead me to believe that there is a problem with  the way MC14+ interact with FLAC files.

I'd be more that willing to send one of the files for tech support to look at it...

Thanks in advance.

Alain

[Alex B]

It is not a common problem. I have FLAC files in various bit depths and sample rates and they play just fine.

Your problem could be caused by incorrect tags. For instance, some ripping programs can add ID3 tags to FLAC files if they are misconfigured.

Here is a quote from the official faq: http://flac.sourceforge.net/faq.html#general__tagging

What kinds of tags does FLAC support?

FLAC has it's own native tagging system which is identical to that of Vorbis. They are called alternately "FLAC tags" and "Vorbis comments". It is the only tagging system required and guaranteed to be supported by FLAC implementations.

Out of convenience, the reference decoder knows how to skip ID3 tags so that they don't interfere with decoding. But you should not expect any tags beside FLAC tags to be supported in applications; some implementations may not even be able to decode a FLAC file with ID3 tags.

MC's FLAC input plug-in has changed a few times since MC12 and it is possible that a file format problem causes audible glitches only with the later versions.

I guess someone would need to inspect a sample file...  (I can do that if you can upload a file somewhere and provide a link.)

EDIT

Just to verify that the problem is really caused by the file, can you hear the "pop" when you play only a single file (i.e. when there is no track transition) and can you always reproduce it when you play the same file again?

[duclosa]

Hello Alex.

Thanks for the prompt reply.

I indeed believe that the problem lies within the files and their interactions with MC, as WavePad plays them just fine.

the problem is indeed reproducible with the same file, each time it is played and also occur when playing just 1 file.

Here is a link to such a file, on RapidShare : http://rapidshare.com/files/386267423/01_-_Mozart-_Horn_Concerto__1_In_D__K_412_-_1._Allegro.flac.html

Thanks for helping. I'm a bit worried by thatproblem, as I recently converted a large number of CDs...

Also, if it can be of any help, the same files, played though MediaMonkey or WinAmp do not display the same behavior.

Alain.

[JimH]

On our wiki, there is an article about "DAC Settings".  Please try it.

[Alex B]

I tested the sample file. The problem is in the file. I'll create a detailed reply later today.

[JimH]

How was the file created?

[Alex B]

Here's what I found.

First I opened the file with a hex editor and checked for incorrect tags. The file has only valid FLAC tags at the beginning of the file. I couldn't see anything that looks like ID3 or some other tags at the end of the file.

Then tested the file with the verifier that is included in the official FLAC package (http://downloads.sourceforge.net/flac/flac-1.2.1b.exe). The file verified OK.

I decoded the file with a few different programs (the official "flac.exe", MC15, Sony Sound Forge Pro and foobar2000). All four produced an exactly identical wave form.

All four produced also the "loud pop" that you described. It consists of 55 apparently erratically stored audio samples at the very end of the audio track in both channels. 55 samples is just a bit more than one millisecond at the 44.1 kHz sample rate.

I have never tried WavPad, but perhaps it doesn't play the last few samples for some reason.

Here is a zoomed-in screenshot from Sony Sound Forge Pro:



I have no idea what could have created such a glitch. Since the file seems to be valid I can only assume that the same "pop" existed already in the wave form that was encoded to FLAC.

That kind of problem is easy to fix with a wave editor. If WavPad doesn't show the problem samples, you can use the Media Editor that is included with MC. You can either trim the file or make the offending samples silent.

[duclosa]

On our wiki, there is an article about "DAC Settings".  Please try it.

.
Nah. It's the interaction of the files and MC14-15. The sames files play OK in 3 other programs. Nothing to do with the DAC. MP3 and WAV files are OK in MC12-15 with the same setup.

Alain.

[JimH]

Nah. It's the interaction of the files and MC14-15. The sames files play OK in 3 other programs. Nothing to do with the DAC. MP3 and WAV files are OK in MC12-15 with the same setup.

It's worth a try.  USB DAC's seem to all be a little different.

[duclosa]

Here's what I found.

First I opened the file with a hex editor and checked for incorrect tags. The file has only valid FLAC tags at the beginning of the file. I couldn't see anything that looks like ID3 or some other tags at the end of the file.

Then tested the file with the verifier that is included in the official FLAC package (http://downloads.sourceforge.net/flac/flac-1.2.1b.exe). The file verified OK.

I decoded the file with a few different programs (the official "flac.exe", MC15, Sony Sound Forge Pro and foobar2000). All four produced an exactly identical wave form.

All four produced also the "loud pop" that you described. It consists of 55 apparently erratically stored audio samples at the very end of the audio track in both channels. 55 samples is just a bit more than one millisecond at the 44.1 kHz sample rate.

I have never tried WavPad, but perhaps it doesn't play the last few samples for some reason.

Here is a zoomed-in screenshot from Sony Sound Forge Pro:

I have no idea what could have created such a glitch. Since the file seems to be valid I can only assume that the same "pop" existed already in the wave form that was encoded to FLAC.

That kind of problem is easy to fix with a wave editor. If WavPad doesn't show the problem samples, you can use the Media Editor that is included with MC. You can either trim the file or make the offending samples silent.

Hello again, Alex.

Thanks for the info.

I believe the files were created with an ealier (pre12) of MC.

If the problem is in the files, as you so convicingly demonstrated, then why does MC12 plays them correctly? I do not really feel like manually editing about 5k files... Is there a workaround? Or am I stuck with MC12 for ever???

Funny thing is all of the files have the same behavior. I'll look into SoundForge to see if it's all the same random bits that are added...

Alain.

[Alex B]

... The sames files play OK in 3 other programs ...

... MC12 plays them correctly...

This is not my experience. I have tried MC15, MC14, MC13, MC12, MC11.1 (with scthom's FLAC plugin), Foobar2000 v.1.0.3, Winamp 5.5, Apollo (an old basic player with its very old FLAC plugin), VUPlayer (another basic player) and Media Player Classic (a DirectShow player which was set to use DC-Bass Source Filter for FLAC decoding). All these programs played the "pop" at the end of your sample file.

Could it be possible that you have cross-fade set in MC12's playback options and that hides the problem?

... I do not really feel like manually editing about 5k files ...

Oh dear, I didn't realize that you have 5000 such files -- or do you mean that you would need to inspect each and every file in order to find the problem files?

If the problem exists in lots of files, it might be useful to find out which program/version/settings combination/etc actually created the files. I.e. can you reproduce the problem? If yes, how? Understanding the cause of the problem might lead to a solution, but there is no guarantee that an easy solution exists.

...to see if it's all the same random bits that are added...

If the offending "pop" seems to be identical in all files and no decoding option can automatically remove it, one possible solution would be to re-encode the files with sox. Sox is a free command line audio editor that can do many kinds of file operations, including file trimming. It is possible to configure MC's external encoder to use sox so that it removes a specified amount of samples from the end of the file (e.g. 55 samples) and encodes a new FLAC file without altering the other samples anyhow.

[duclosa]

hum.

Puzzled, here.

In both MC12 and 14, track switching is set to aggressive, -1s, and "do not play silence leading and trailling

Is there any other option I'm overlooking?

I've looked at sox. Not easy. It does not do anything when prompted with "sox *.flac *.flac trim 0 60s"

loosing hope...
going to bed...

Alain.

[Alex B]

In both MC12 and 14, track switching is set to aggressive, -1s, and "do not play silence leading and trailling

Is there any other option I'm overlooking?

I don't know if the track transition effects have changed anyhow after MC12, but in order to test file decoding you should set the "Track Change" settings to plain "Gapless" (i.e. no cross-fade and no silence removal). Otherwise the complete audio track might not be played exactly as it is.

I've looked at sox. Not easy. It does not do anything when prompted with "sox *.flac *.flac trim 0 60s"

Sox processes files from the beginning to the end. You can remove samples from the end if you first reverse the file, then trim it, and finally reverse it once again.

For instance, in a CMD window you can use a command line like
sox 1.flac 2.flac reverse trim 55s reverse
to cut 55 samples from the end. (In this example sox.exe and the source file, 1.flac, are in the current directory. 2.flac is the destination file.)

Here is an example of the External Encoder settings:



--temp F:\Temp --buffer 65536 %IN --compression 5 %OUT reverse trim 55s reverse

I included some optional parameters:
--temp  sets the temp location. If not set, sox uses the OS default.
--buffer  is the amount of memory buffer in bytes. The default is 8192. (I have not actually tested if increasing the buffer has any effect to the processing speed).
--compression  sets the FLAC compression level. In my opinion 5 is quite optimal. (The sox default is 8, but that might be unnecessarily slow. It can compress only slightly more than 5.)

Here is the string without the optional parameters:
%IN %OUT reverse trim 55s reverse

[duclosa]

Hi Alex!

You relly know your nuts.

Sox correctly removed the offending samples at the end of the Flac files. The files now play flawlessly. Everything was done from within MC14, with the command line parameters you suggested.

Thanks again.

BTW, which program would you recommend to rip CDs to FLAC? I'm a bit weary after this first disastrous experience...

Alain.

[Alex B]

BTW, which program would you recommend to rip CDs to FLAC? I'm a bit weary after this first disastrous experience...

MC's ripper has a good secure mode and it is nicely integrated in ... MC.  
Here is an old thread that might be useful: How can I ensure quality of a ripped music file (the settings have now a bit different layout, but otherwise it is still a useful thread).

If you know what you are doing and really want to control all settings & ripping features and use an external ripper EAC is probably the best option. You can find the most up-to-date info here: http://wiki.hydrogenaudio.org/index.php?title=EAC

[duclosa]

Thanks, Alex. Your help has been much appreciated.

Alain.