BUG? m4a ALAC playback is "weird" on some files

[MrSinatra]

latest 5.7 beta, no 3rd party plugins, win7 64

ok, this is a weird one.

I am converting all my FLACs to m4a ALAC. now, some of the flacs are weird, b/c they were made from weird wavs years ago, in the sense that the sample rates, bit rates, etc are odd, low, whatever. but nevertheless they play just fine.

so I convert to ALAC and on playback winamp does some weird stuff.

first, some simply sound different, and its an obvious difference, not subjective, so that's weird.

second, the bitrate is freq reported wrong in the player window, (often too big to fit) and not even consistently in its incorrectness, also weird.

third, in spite of these weird things, the RG sets the values EXACTLY the same for each, which to me indicates that the files are identical, so why would they sound different? weird.

if the problem is the conversion, why would the RG be identical? is there an app that compares lossless files to see if they are identical?

I have attached a zip file so you can see for yourselves.

EDIT: I would also add that winamp's ALAC handling seems a bit "rough" in that it pauses longer when editing metadata on the playing song, takes longer to rate (playing or not), takes longer to do RG analysis to, etc.

[MrSinatra]

perhaps I should add that the FLACs were made with either the FLAC frontend, or by audacity after importing the wav, (to the best of my recollection, it was some time ago). however, I did compare the FLACs to the wavs (pre-RG, and before deleting the wavs obviously) and they sounded exactly the same.

I do have other examples other than whats in the zip, if anyone would like them?

[ryerman]

Originally Posted by MrSinatra

.......now, some of the flacs are weird, b/c they were made from weird wavs years ago, in the sense that the sample rates, bit rates, etc are odd, low, whatever. but nevertheless they play just fine.......

They play in Winamp, but there might be something funky with them besides unusual bit rates and sample rates.
All except "greetings.flac" and "fine.flac" crash VLC.
All except "greetings.flac" are silent in Audacity.
"greetings.flac" is played only partially in VLC.

After re-encoding with ffmpeg, all those problems disappear.

But does that have anything to do with what you observe when playing the .m4a files?
I can't answer.

I see the weird bit rates of your.mp4 files. Mp3tag shows different bit rates, compared with the .flac files, but not even close to what Winamp shows.

I didn't notice any glaring difference in sound quality at first but while I was doing some testing, all kinds of weird shit happened when playing those short .m4a files.
Extreme static, an unchanging bit rate shown as each file was played, and then sometimes normal playback again, without any obvious pattern.
Maybe that's a result of the "rough" ALAC handling you describe.

Transcoding these "corrected" .flac files to .m4a, again with ffmpeg, did not change their behaviour in Winamp.

So I guess the next step will be to find or create some pristine, short .m4a files and play around with them in Winamp.
I think it's best to remove the possibility that the original .flac files are the origen of any problems.

Just in case it matters, the decoder used is Nullsoft MP4 Demuxer v2.62 (in_mp4.dll)

And just to be clear;
"After very careful consideration sir, I've come to the conclusion that yer new defence system sucks."

[MrSinatra]

hi,

thx for your testing, its appreciated.

curiously, Egg hasn't responded. I hope he does.

anyway, you said a lot of things here, so i'd like to state things and you can tell me if it is correct or not:

Originally Posted by ryerman

They play in Winamp, but there might be something funky with them besides unusual bit rates and sample rates.
All except "greetings.flac" and "fine.flac" crash VLC.
All except "greetings.flac" are silent in Audacity.
"greetings.flac" is played only partially in VLC.

After re-encoding with ffmpeg, all those problems disappear.

But does that have anything to do with what you observe when playing the .m4a files?
I can't answer.

are you using the latest 5.7b without any 3rd p.plugins? OS?

I have not tested with VLC myself, but perhaps the problem is with VLC? i'm not saying there isn't a problem with the FLACs, but I would not know how to prove it one way or the other. I do use max compression, did you?

in any case, they all do play in winamp for you, yes? I see no odd behavior with the FLACs in winamp.

likewise, the m4a's all play, but I do see and hear odd behavior with them.

Originally Posted by ryerman

I see the weird bit rates of your.mp4 files. Mp3tag shows different bit rates, compared with the .flac files, but not even close to what Winamp shows.

you see the weird bitrates in the player window? do you see them alternate? sometimes too big, sometimes much smaller? so mp3tag agrees with winamps FLAC bitrate reporting, but not the m4a reporting? what about in winamp's view file info dialog?

Originally Posted by ryerman

I didn't notice any glaring difference in sound quality at first but while I was doing some testing, all kinds of weird shit happened when playing those short .m4a files.
Extreme static, an unchanging bit rate shown as each file was played, and then sometimes normal playback again, without any obvious pattern.
Maybe that's a result of the "rough" ALAC handling you describe.

I have not had any static or anything like that. do you use any 3rd party codecs? the audio differences were in loudness and tone. I sorted all the clips by title, and then played them all back to back, with some quality earbuds in my ears, and the differences, on some tracks were clearly obvious. can you try with headphones?

the rough ALAC/m4a handling was more about the editing of metadata and the manipulation of the files, but getting the bitrate right would come under that description as well. the m4a ALAC experience in winamp just doesn't feel as polished as most of the other formats, which is to be expected I guess, but I think it should be reported and fixed.

as an aside, interestingly, I haven't had any problems with the short tracks getting skipped doing this, (as per my sig), which is mildly surprising but might just be a fluke, (or due to changing/alternating formats).

Originally Posted by ryerman

Transcoding these "corrected" .flac files to .m4a, again with ffmpeg, did not change their behaviour in Winamp.

that indicates to me that winamp itself has problems, at least with these kinds of ALACs.

Originally Posted by ryerman

So I guess the next step will be to find or create some pristine, short .m4a files and play around with them in Winamp.
I think it's best to remove the possibility that the original .flac files are the origen of any problems.

I would if I knew how to create ALACs, as opposed to transcode things into them. I suspect its the files specs, but i'm just guessing.

Originally Posted by ryerman

Just in case it matters, the decoder used is Nullsoft MP4 Demuxer v2.62 (in_mp4.dll)

mine is 2.63

Originally Posted by ryerman

And just to be clear;
"After very careful consideration sir, I've come to the conclusion that yer new defence system sucks."

I would not recommend pissing on a sparkplug however.

[ryerman]

Hi MrSinatra

I bet it's a big job converting your library and I hope this is the worst of any problems!

My system basics are in my signature but I've attached an Info Report, in case it's helpful.
Otherwise, I'll hold off from any detailed response.
Instead, I may have a work-around for the undesirable behaviour of your example .m4a files.

Try the attached files.
They were transcoded from your example mono .flac files, but into stereo .m4a.
For me, the weird playback issues disappeared and the bit rates are shown consistently in Winamp. They agree with Mp3tag (+-1 kbps). But still, not with the .flac originals.

Afterwards, if you still want, I can answer your questions.

I think 1 or both of 2 things are happening:
1. GIGO: the flac files are faulty (even though they play in Winamp) and therefore the resulting .m4a files are faulty.
2. Winamp doesn't like mono .m4a.

But I'm just guessing out loud.

[MrSinatra]

Originally Posted by ryerman

Hi MrSinatra

I bet it's a big job converting your library and I hope this is the worst of any problems!

thx again for your testing.

actually, the vast majority of my stuff is EAC ripped 256kbps mp3, at q1 and lame 3.96 or higher. contrary to [audio forum's] popular opinion, I don't think most people could tell the difference in a double blind test between a HQ mp3 and a FLAC (or lossless) file, and esp not in most real world listening scenarios. Having said that, I did do the Beatle remasters in FLAC, and I have some other FLACs as well, mostly from DLs or a few DVD rips, or wav/ape/shorten conversions, etc. I will make mp3 dupes of them for portables later. while I doubt I could discern the difference, I do think the Beatles, Pink Floyd, and some other landmark albums warrant the treatment, esp since the difference in HD space for cherry picked albums isn't really a concern.

what I have to find out is a good way to rip to m4a/ALAC directly, so I can skip a FLAC step. I might try cuetools ripper, if I find EAC too difficult to configure to rip to ALAC. there are some things I haven't reached a conclusion on yet, as some vers of ALAC seem to allow for compression options and so on that maybe ffmpeg or ref vers don't, but that's for another thread.

the job then isn't too big, the conversions are fairly easily, its in getting the existing tagging to be equal, that's tedious. my ultimate goal is to have everything in either ALAC or mp3, (and ergo apple/istuff/winamp friendly). at some point I will go back and cherry pick what albums I want to upgrade from mp3 to ALAC, (and of course, re-rip).

Originally Posted by ryerman

My system basics are in my signature but I've attached an Info Report, in case it's helpful.
Otherwise, I'll hold off from any detailed response.

why no 5.65 or 5.7? you could do tests on my files in safe mode tho, even on 5.64

Originally Posted by ryerman

Instead, I may have a work-around for the undesirable behaviour of your example .m4a files.

Try the attached files.
They were transcoded from your example mono .flac files, but into stereo .m4a.
For me, the weird playback issues disappeared and the bit rates are shown consistently in Winamp. They agree with Mp3tag (+-1 kbps). But still, not with the .flac originals.

I have tried your files, and yes the bitrates in the player window are now consistent. that's an improvement. they also sound better, but that's both good and bad.

its good they sound better, but mono into stereo should be a transparent change, and the files should sound exactly the same, but they don't. just like my FLAC > ALAC conversions, they sound "different." they also result in different RG values, which is expected given the mono to stereo re-encoding.

I have taken your files, and added them to mine, and attached them to this post. if you could sort by title and listen to all these with earphones in, i'd really like to hear your feedback on that.

as to the kbps, I also find that odd. I would not expect the kbps to be exactly the same between FLAC/ALAC, but def close. I also can't explain the big differences between winamp and mp3tag.

Originally Posted by ryerman

Afterwards, if you still want, I can answer your questions.

I think 1 or both of 2 things are happening:
1. GIGO: the flac files are faulty (even though they play in Winamp) and therefore the resulting .m4a files are faulty.
2. Winamp doesn't like mono .m4a.

But I'm just guessing out loud.

it def seems winamp doesn't like mono m4a ALAC, or at least those with odd / low specs.

I still have a problem with the GIGO theory, in that they may well be garbage, but I don't see the proof of that.

anyway, interested to hear your listening tests with earbuds results.

EDIT: I did minor tag edits to make the comparisons easier to do, and also added RG. I also noticed in mp3tag the "Mode" column lists 1 or 2 for channels for mp3/m4a, but "Mono" and presumably "Stereo" for FLAC.

[ryerman]

I don't have earbuds but I listened (in Safe Mode) with some old headphones as well as with the stereo system speakers.

For each example, each encoding sounds the same to me.

If there were (are?) drastic and obvious differences in the sound of the different encodings, our personal set-ups wouldn't matter much.
But we don't have identical hardware and software, not to mention brains and ears. That could explain our differing experience if there are only subtle differences in the files.
Or maybe I should schedule an appointment with an audiologist.

As for your original .flac files; I can't prove they are garbage. So I'm just relying on the circumstantial evidence mentioned in my first post.
The fact that they play in Winamp does not guarantee that they are not faulty.

I'm still using 5.64 because I'm annoyed that there are now 2 Winamps. For a while there seemed to be new builds every few days for each version.
Who could tell how long that would last?
I'll wait until 5.7 comes out of beta, when I hope and assume 5.65 (and/or 5.66, 5.67 etc.) will no longer be supported.

[DrO]

Originally Posted by ryerman

I'm still using 5.64 because I'm annoyed that there are now 2 Winamps. For a while there seemed to be new builds every few days for each version.
Who could tell how long that would last?
I'll wait until 5.7 comes out of beta, when I hope and assume 5.65 (and/or 5.66, 5.67 etc.) will no longer be supported.

we put out updates and people complain. we don't put out updates and people complain. there's just no way to win. we clearly mark 'official' builds and 'labs' builds and it still gets us in the wrong.

v5.64 and v5.65 are roll ups of non-Cloud fixes (with 5.65 fixing a nasty library import issue in v5.64) which were also being added as part of the v5.7 betas. when there were enough changes / fixes to warrant a newer v5.6x build then that's what we've done as a lot of people won't use the betas even though it's only 'beta' due to the Cloud functionality.

so the v5.7 beta is just whatever was the last v5.6x release with Cloud functionality and non-Cloud changes (depending on what time you are from the last v5.6x release and the current v5.7 build) present. but only the v5.6x are the officially supported versions (though i do what i can to resolve issues reported from people using the v5.7 builds as that then helps resolve things for the next v5.6x release), so v5.65 is the currently supported version (unless advised / chosen by the user to try out what is going to become the next v5.6x build or whatever number is decided upon).

and v5.7 is purely just a way to distinguish what is a rolling open beta and could have been named as just 'labs' or something like that without following the v5.x naming scheme.

[MrSinatra]

DrO, if you are going to post in this thread, I would appreciate it if you would address the topic of the thread, and not drag it off topic. personally, I have no problem with winamp's release conventions, I really appreciate having an official and a beta release, and its ok with me if the official release happens to need multiple releases in a short time; but I can understand why someone else might be frustrated by that. I just don't think winamp has a better alternative to that, than what its doing.

perhaps you can split your post and this one off into their own thread and then link it to back here?

and I think academically speaking, you'd find the problems presented by the last attachment interesting, b/c there is no obvious answer to the observed behavior.

[DrO]

i replied to what i thought was relevant with the time available - everything else needs a few hours (or more) to just read through it and i just don't have that time (or interest at the moment). and i'll probably split out my post later, but i have more important things to do at the moment.

[MrSinatra]

hi Ryerman,

I finally got the time to do proper listening tests. see below:

Originally Posted by ryerman

I don't have earbuds but I listened (in Safe Mode) with some old headphones as well as with the stereo system speakers.

For each example, each encoding sounds the same to me.

If there were (are?) drastic and obvious differences in the sound of the different encodings, our personal set-ups wouldn't matter much.
But we don't have identical hardware and software, not to mention brains and ears. That could explain our differing experience if there are only subtle differences in the files.
Or maybe I should schedule an appointment with an audiologist.

I am using an alienware laptop with SSD. that's important b/c mechanical system drives tend to bleed noise into the headphone jack of laptops. the files are on a usb 3.0 1TB drive, but would sound the same even if on the SSD.

I am also using a nice set of earbuds, not real expensive but not cheapo either. I do think its important to have earbuds since you can really get proper feedback when comparing files. for instance, I use them to decide between orig vers and remasters (remasters aren't always necessarily better!)

anyway, take my last attachment, it has our files in it. put them in track # order, then title order. they will then go: orig flacs, my ALAC conversions (conv), your ALAC stereo conversions. I have RG track on for all of them.

imo some sound the same basically, while others are drastically different, meaning not subtle or a shade of difference, but different enough so you could always tell them apart easily.

here are my results:

chess2 = orig sounds muted, more static than signal by comparison to the other two, the conv sounds better, fuller, much louder, and yours sounds even just a bit more fuller and echo-ier than the conv

excellent = the orig sounds quiet, the other two sound louder and basically the same

fine = ditto excellent

greetings = this is one where all 3 sound basically the same.

playgame = ditto excellent

sprkplug = ditto excellent, although if someone said ditto chess2 just not as pronounced, I wouldn't argue

sucks = ditto chess2; after several listens, I think your conv sounds a bit better than mine, more natural

in all cases, either conv is better than the orig, and louder.

it is important to point out that I am hearing clear differences between my flacs and my alacs, even though the RG value is in most cases EXACTLY the same. your values are different, but your files are mono-> stereo conversions, and so I would expect them to be somewhat different, but they are in some cases drastically different, and really, its weird b/c it should just be 2 channel mono, so I can't explain the specs or the better sound!

Originally Posted by ryerman

As for your original .flac files; I can't prove they are garbage. So I'm just relying on the circumstantial evidence mentioned in my first post.
The fact that they play in Winamp does not guarantee that they are not faulty.

I agree, and I wouldn't even know how to approach the issue.

maybe flac only officially supports some specs and semi unofficially others? or maybe what I made from the original wavs, (which themselves were oddballs) has faulty header info or something, although again they were made with either the 1.2.1 Flac frontend, or Audacity using 1.2.1

...OR it may be the case that the apps / results from your first post are simply less tolerant than winamp is?

but what seems to be true is the following:

1. winamp has a problem with displaying the proper bitrate on some ALACs.
2. winamp likely has a problem with mono ALACs, and/or maybe ALACs with "low specs."
3. winamp seems to be slower handling ALAC metadata than other formats.

its clear to me that the devs need to at least look into ALAC handling and behavior. the concern is that I might be making a fairly serious erroneous assumption, and winamp actually is not handling HQ ALACs properly either; but just isn't "as obvious" about what its doing wrong as it is here with these examples.

eventually I will run the same listening tests as above with another player. I am very curious as to whether its winamp making them sound different, or the files themselves, (I suspect the files).