PDA

View Full Version : First sec of song getting clipped off



4mula1
2006-05-06, 03:23
After upgrading to SS 6.2.2 I've noticed that when I manually advance to the next song it will sometimes not play the first second or so of the track. I don't remember this with 6.2.1 but recently I have been converting my collection from mp3/ogg to flac. So far this issue only seems to occur with flac tracks. SB3/FW48 connectied wirelessly to a Linksys WAP54g access point. Anybody else having this issue?

radish
2006-05-06, 09:11
I have heard others mention this problem, but I forget who. It also sounds like it may be related to this bug : http://bugs.slimdevices.com/show_bug.cgi?id=1434 as there has been some suggestion that it's missing the start of the next track rather than the end of the current one. It's often hard to tell which.

shawkie
2006-05-06, 09:17
I'm sure that the problem I was having was with the end of tracks. I haven't re-tested it recently to check its still there but since nobody is claiming to have fixed it...

cepheid
2006-05-06, 23:43
As reported in this thread, I'm fairly certain it's the beginning of tracks. Yes, it occurs only with FLAC... in my case, it's when ALAC is transcoded to FLAC before streaming to the SB.

It's rather annoying and also screws up gapless playback... hopefully it will be fixed soon.

4mula1
2006-05-07, 07:20
When it happens to me it's not during uninterrupted playback, but when I start a new track while it's playing. It doesn't seem to matter if I just use the next button or scroll through my playlist and pick a new song.

radish
2006-05-07, 08:54
It seems as if there may be a number of issues both at the start and end of tracks :) Slim, I'd say all is not well in the land of FLAC playback!

shawkie
2006-05-07, 09:40
I've just re-tested 6.5 (nightly from a day or two ago) and for the track I'm using I get the start of the track correctly but I'm missing about 6/100 sec at the end of the track. This is playing a single track on its own and comparing the analog output of the squeezebox with the original FLAC file in Nero WaveEditor.

mrtaber
2006-05-07, 10:01
I have noticed this, too. Clipping at the beginning or the end of a FLAC track. Let's say I'm just playing a playlist. Sometimes, beginning of the song is clipped, at other times, it's the end--most often, neither. If it's the beginning, and I hit 'back' to start it over, it doesn't clip!

Here's hoping they'll figure out what's going on and fix it soon. I love my Squeezeboxen (I'm still in the honeymoon phase), but it's really jarring to have a song just "yanked offstage" like in the cartoons...

Mark :)

radish
2006-05-07, 15:21
Just FYI - there is a workaround which I have used for the past year since I first reported this :) If you disable native FLAC and stream as WAV it seems to all be good. Of course you lose ff/rew and gain bandwidth usage, but at least the music sounds right. Please also vote for the bug (1434).

mrtaber
2006-05-07, 16:54
Thanks, Radish. I would just go to server/file types and uncheck flac/flac, leaving flac/wav? I guess that means I'll be able to participate in the Audiophile discussion too (flac-to-wav sounding better than the built-in flac decoder)--I wonder if I'll hear a difference? :)

Again, thanks
Mark :)

PS: Just voted for bug 1434.

radish
2006-05-07, 18:30
Thanks, Radish. I would just go to server/file types and uncheck flac/flac, leaving flac/wav? I guess that means I'll be able to participate in the Audiophile discussion too (flac-to-wav sounding better than the built-in flac decoder)--I wonder if I'll hear a difference? :)

Again, thanks
Mark :)

PS: Just voted for bug 1434.

Yes, just disable flac/flac and leave flac/wav. You may also have to disable wav/flac as otherwise I think it does flac->wav->flac->sb, which is clever but not quite what we had in mind :)

Fuseball
2006-06-02, 12:35
Just got my SB3. Lovely bit of kit, but I'm getting the same problem with it clipping the first second of each track. This is happening with AAC and MP3 tracks, not just FLAC. Sure hope they get this fixed, although I don't know that it's necessarily related to bug 1434.

Cheers
Ian

cepheid
2006-06-02, 13:54
Just FYI - there is a workaround which I have used for the past year since I first reported this :) If you disable native FLAC and stream as WAV it seems to all be good. Of course you lose ff/rew and gain bandwidth usage, but at least the music sounds right. Please also vote for the bug (1434).
On another thread, there seems to be disagreement about this at least as it relates to ALAC decoding. It would appear that the FLAC bug and the ALAC bug are separate (though they may be related).

Fuseball, this is the first I've heard of it happening with AAC and MP3... however, you are aware those are not designed for gapless playback, right?

Fuseball
2006-06-02, 14:23
On another thread, there seems to be disagreement about this at least as it relates to ALAC decoding. It would appear that the FLAC bug and the ALAC bug are separate (though they may be related).

Fuseball, this is the first I've heard of it happening with AAC and MP3... however, you are aware those are not designed for gapless playback, right?
You're absolutely right. MP3 playback is fine. I foolishly saw the a 192 bitrate and assumed it was an MP3 I was playing! It's just AAC that is causing me a problem, which is unfortunate as my entire CD collection was ripped as AAC a couple of years ago.

Reading that other thread and the associated bug report makes me think that I must have the same problem as they describe. Anything being decoded by the mov123 decoder skips the first half second of the track.

Thanks for the help.

radish
2006-06-02, 15:46
According to bugzilla 1434 is now fixed, so as soon as I can get my hands on firmware 52 we'll see if these are the same bugs or not :)

Fuseball
2006-06-02, 16:31
According to bugzilla 1434 is now fixed, so as soon as I can get my hands on firmware 52 we'll see if these are the same bugs or not :)
Fingers crossed. I'm not relishing the thought of re-ripping everything. Took me almost a year last time. :)

cepheid
2006-06-14, 21:01
Now that bug 1434 is fixed, let's all vote for bug 2095 so ALAC can play back gaplessly as well! =)

jdryyz
2006-08-13, 17:56
I have this same problem with my setup and have experienced it from day one of ownership (I have the squeezebox2). I believe I started with 6.0.x back then.

I am currently running slim server 6.3.1 (firmware 55) on my Mac Mini (1.42GHz, OS 10.4.7, 512MB RAM). My music library consists of over 2000 songs in AAC format encoded at 192kbps and stored in an external firewire drive. The bahavior of skipping or clipping the first second of tracks isn't consistent in my case. The majority of time it *does* occur, but there are cases where it does not happen.

I was thinking it may be file fragmentation or my relatively low system RAM, but this should not be the case since a) the OSX file system is supposed to be fragmentation-free (at least that's what I've been told) and b) my 512MB RAM size isn't being taxed by the server activity.

Any other ideas on how to eliminate this problem are apprecaited. I'm very happy with the product is every other way.

Thanks,

Jeff

*EDIT* I have to add a couple of more things-- I have noticed the clipping when songs advance to the next track on there own and when I use the FWD button. Sometimes there are even delays in starting the next song whether the clipping occurs or not. This is perhaps explained by shuffled playback.

I use the sb2 over coaxial digital. I do not believe I have the problem described here:

http://forums.slimdevices.com/showthread.php?t=26307&highlight=beginning+song

stinkingpig
2006-08-13, 19:21
On 8/13/06, jdryyz <jdryyz.2ci95z1155517201 (AT) no-mx (DOT) forums.slimdevices.com>
wrote:
>
>
> I have this same problem with my setup and have experienced it from day
> one of ownership (I have the squeezebox2). I believe I started with
> 6.0.x back then.
>
> I am currently running slim server 6.3.1 (firmware 55) on my Mac Mini
> (1.42GHz, OS 10.4.7, 512MB RAM). My music library consists of over 2000
> songs in AAC format encoded at 192kbps and stored in an external
> firewire drive. The bahavior of skipping or clipping the first second
> of tracks isn't consistent in my case. The majority of time it *does*
> occur, but there are cases where it does not happen.
>
> I was thinking it may be file fragmentation or my relatively low system
> RAM, but this should not be the case since a) the OSX file system is
> supposed to be fragmentation-free (at least that's what I've been told)
> and b) my 512MB RAM size isn't being taxed by the server activity.
>
> Any other ideas on how to eliminate this problem are apprecaited. I'm
> very happy with the product is every other way.
>
> Thanks,
>
> Jeff


Based on the rest of the messages in this thread, it seems like the relevant
information is actually downstream of the SB, rather than upstream to the
computer running SS... I don't know anything more than that, but you might
want to post what kind of stereo you've plugged the SB into, and how.

--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional

jdryyz
2006-08-13, 19:41
On 8/13/06, jdryyz <jdryyz.2ci95z1155517201 (AT) no-mx (DOT) forums.slimdevices.com>
wrote:
>
>
> I have this same problem with my setup and have experienced it from day
> one of ownership (I have the squeezebox2). I believe I started with
> 6.0.x back then.
>
> I am currently running slim server 6.3.1 (firmware 55) on my Mac Mini
> (1.42GHz, OS 10.4.7, 512MB RAM). My music library consists of over 2000
> songs in AAC format encoded at 192kbps and stored in an external
> firewire drive. The bahavior of skipping or clipping the first second
> of tracks isn't consistent in my case. The majority of time it *does*
> occur, but there are cases where it does not happen.
>
> I was thinking it may be file fragmentation or my relatively low system
> RAM, but this should not be the case since a) the OSX file system is
> supposed to be fragmentation-free (at least that's what I've been told)
> and b) my 512MB RAM size isn't being taxed by the server activity.
>
> Any other ideas on how to eliminate this problem are apprecaited. I'm
> very happy with the product in every other way.
>
> Thanks,
>
> Jeff


Based on the rest of the messages in this thread, it seems like the relevant
information is actually downstream of the SB, rather than upstream to the
computer running SS... I don't know anything more than that, but you might
want to post what kind of stereo you've plugged the SB into, and how.

You must have quoted my message at a point in time just before I added my edit (only a few minutes had passed):

~~~~~~~
*EDIT* I have to add a couple of more things-- I have noticed the clipping when songs advance to the next track on there own and when I use the FWD button. Sometimes there are even delays in starting the next song whether the clipping occurs or not. This is perhaps explained by shuffled playback.

I use the sb2 over coaxial digital. I do not believe I have the problem described here:

http://forums.slimdevices.com/showth...beginning+song
~~~~~~~

I'm more inclined to think it *is* something upstream from the sqeezebox myself, but just to satisfy any concerns the sb2 is connected to a Yamaha RX-V1.

cepheid
2006-09-13, 15:41
Based on the rest of the messages in this thread, it seems like the relevant
information is actually downstream of the SB, rather than upstream to the
computer running SS...
I might agree if everyone were using digital output from the SB and this could be attributed to processing delay in the receiver. I, however, am using the analog output, and therefore I don't see any way how anything downstream from the SB could cause this clipping so consistently. I am quite confident the problem resides somewhere in the SlimServer package, most likely in the mov123 executable. I realize that mov123 is just a simple wrapper to the Quicktime API but that is the only consistent software between all of the people who report this bug. People who have switched to the 'alac' executable report that it solves the problem (and this is the current official fix as reported on bugzilla). It's weird that this bug would occur with a wrapper to the API but not with a native API call (e.g. from iTunes), but that's the way it appears...

Eric Seaberg
2006-12-24, 18:27
I posted to this problem a LONG time ago. I'm having it happen on both an SB3 and Transporter using digital outs. The devices themselves are set to NOT turn off the digital stream when off, which makes no difference. I can listen to the encoded files on any playback software and they're all OK.

This is DEFINITELY a SERVER issue, as it DOES happen with SoftSqueeze, too.

I'm not doing ANYTHING crazy with the files! Most are Apple AAC and the CUT-OFF issue doesn't happen with all AAC files.

THIS IS UNACCEPTABLE!!

SlimServer Version: 6.5.1 - 10992 - Mac OS X 10.4.8 (8L2127) - EN - utf8
Perl Version: 5.8.6 darwin-thread-multi-2level
MySQL Version: 5.0.22-standard
Mac OS 10.4.8 - server running on Mac MINI
1.83GHz Intel Core Duo w/ 2GB RAM

Eric Seaberg
2006-12-25, 10:11
Merry Christmas to you all! Before the family started opening gifts this morning I did a little testing.

I opened one of the files that is missing the beginning few samples and confirmed what it's doing.

This ENTIRE CD plays this way... it was ripped using iTunes AAC @ 256kbps VBR, as I've done with most of my library. Not everything has this problem, so I thought I'd open the original CD and look at the PQ coding with my CD mastering software (I do this for a living so DON'T TRY THIS AT HOME).

The actual start of the song is 14 CD frames from the PQ start mark (there are 75 frames per second on a CD) and this translates to roughly 190ms. SlimServer is missing not only the start mark, but misses up to the first 350ms (26 CD frames). Again, this does NOT happen on every album that is ripped using this format, and has even happened with PURCHASED albums where I can select AAC as the preferred format (I never do anything less than 256kbps VBR and typically use 320kbps CBR).

I will do some more testing this afternoon as time allows re-ripping this album as FLAC and raw AIFF to see if that makes a difference.

I have played these files on multiple computers in the house using iTunes SHARING without issue, as well as opening the offenders with an editing program. This doesn't make sense!!! I'm hoping to narrow it down somehow, but sure wish SD will look into it further.

I'll help in any way I can!!


Have a great holiday, everyone!!

(Go CHARGERS!!)

Eric Seaberg
2006-12-25, 14:38
OK, a little more info here...

I took the same tune encoded raw AIFF, MP3 LAME @ 320k and MP4 (AAC) @ 256k using a program called BarbaBatch.

We use BarbaBatch exclusively at our post-production studios for sample rate and format conversion. It is, pretty much, the standard by which all other software SRC programs are judged.

Besides the above 3 formats, I used MAX to rip a FLAC version of the tune.

Even after playing with the file types for the server, mainly AAC conversion using LAME, FLAC, etc., I could NOT get the AAC to play with a clean start. However, all other file types were OK. So... I'm guessing there's something going with with the AAC conversion using WHATEVER to stream to the playback boxes.

Again, this does not happen to ALL AAC files, and I could easily look at the ones that DON'T to see where the song start happens based on the start mark.

SD, what's next?!

peter
2006-12-26, 00:07
Eric Seaberg wrote:
> OK, a little more info here...
>
> I took the same tune encoded raw AIFF, MP3 LAME @ 320k and MP4 (AAC) @
> 256k using a program called BarbaBatch.
>
> We use BarbaBatch exclusively at our post-production studios for sample
> rate and format conversion. It is, pretty much, the standard by which
> all other software SRC programs are judged.
>
> Besides the above 3 formats, I used MAX to rip a FLAC version of the
> tune.
>
> Even after playing with the file types for the server, mainly AAC
> conversion using LAME, FLAC, etc., I could NOT get the AAC to play with
> a clean start. However, all other file types were OK. So... I'm
> guessing there's something going with with the AAC conversion using
> WHATEVER to stream to the playback boxes.
>
> Again, this does not happen to ALL AAC files, and I could easily look
> at the ones that DON'T to see where the song start happens based on the
> start mark.
>

Perhaps you should convert your Apple codec encoded files to something
less proprietary (flac, ogg) and next time think twice before committing
to a commercial company that keeps it's formats secret just to lock you in.
> SD, what's next?!
>

This is not support (AT) slimdevices (DOT) com

Regards,
Peter

Eric Seaberg
2006-12-26, 08:12
It may be proprietary, but Apple isn't stopping other developers from using it. I have many audio apps that can write and read AAC encoded files, however their DRM is certainly another issue.

Jacob Potter
2006-12-26, 17:44
On 12/25/06, Peter <landen-slimp (AT) frg (DOT) eur.nl> wrote:
> Perhaps you should convert your Apple codec encoded files to something
> less proprietary (flac, ogg) and next time think twice before committing
> to a commercial company that keeps it's formats secret just to lock you in.

AAC is not "secret", nor is it Apple-specific. It's an MPEG standard.

- Jacob

peter
2006-12-27, 00:26
Jacob Potter wrote:
>
> AAC is not "secret", nor is it Apple-specific. It's an MPEG standard.

Is this also true for the lossless codec (which is what we're talking
about here)?

Peter

Jacob Potter
2006-12-27, 12:05
On 12/26/06, Peter <landen-slimp (AT) frg (DOT) eur.nl> wrote:
> Is this also true for the lossless codec (which is what we're talking
> about here)?

Apple Lossless is closed, but I didn't see Eric mention that anywhere...

> This ENTIRE CD plays this way... it was ripped using iTunes AAC @
> 256kbps VBR, as I've done with most of my library.

Some people are experiencing this issue with Apple Lossless, yes, but
not all of them.

- Jacob

cepheid
2006-12-28, 00:05
Some people are experiencing this issue with Apple Lossless, yes, but not all of them.I believe the problem has been tracked to the mov123 executable, although nobody has yet figured out WHY the executable should be experiencing this because it is a simple wrapper to the QT library calls. Although I have not yet verified this, the alac executable which is now used to play ALAC files should not experience this issue. Anyone playing ALAC files with the mov123 executable will experience it. Similarly, since AAC is played using mov123, it will also experience it. To solve this issue, either mov123 needs to be fixed (somehow!) or needs to be entirely replaced (like was done with the alac executable).

peter
2006-12-28, 02:36
Jacob Potter wrote:
> On 12/26/06, Peter <landen-slimp (AT) frg (DOT) eur.nl> wrote:
>> Is this also true for the lossless codec (which is what we're talking
>> about here)?
>
> Apple Lossless is closed, but I didn't see Eric mention that anywhere...

This discussion started (at least in the mailing list view) with a
posting by Tikigod called "Annoying Apple Lossless Issue" to which Eric
replied, so to my mind we're talking about lossless
..
>
>> This ENTIRE CD plays this way... it was ripped using iTunes AAC @
>> 256kbps VBR, as I've done with most of my library.

I didn't say that, so your quoting must be off.

Regards,
Peter

Eric Seaberg
2006-12-29, 09:50
Sorry guys, I've been without access for several days and just got back online.

I AM talking about AAC as I didn't check any Apple Lossless files, and will do that as soon as I get back home on New Year's Eve. I, also, believe it's the call to Quicktime that causes the problem.

I also need to confirm why not all AAC files are doing this. I may have to look at the PQ coding of the GOOD ones to see where the start mark is compared to the beginning of audio. I'll get as much info together as I can and get back to this thread.

I'd really rather NOT re-rip everything with FLAC. I have thought about it just to get the extra quality bump, but iTunes won't read them which, for me anyway, REALLY puts a crimp in my tag editing and organization for SlimServer. As a Mac user, there just aren't as many options to work with FLAC yet.

Phil Karn
2006-12-29, 10:05
Eric Seaberg wrote:

> I'd really rather NOT re-rip everything with FLAC. I have thought
> about it just to get the extra quality bump, but iTunes won't read them
> which, for me anyway, REALLY puts a crimp in my tag editing and
> organization for SlimServer. As a Mac user, there just aren't as many
> options to work with FLAC yet.

I've standardized on FLAC for my library collection (with subsequent
conversions to Ogg Vorbis, MP3 or AAC as needed for portable jukeboxes),
but I also like to rip with iTunes for the convenience.

So my technique is to use ALAC when ripping, copy the ALAC files to the
Linux server running SlimServer, and batch convert ALAC to FLAC with a
little perl script I just wrote. The only hard part is converting the
tags, but I think I do pretty much the right thing.

Anybody who wants my script is welcome to it.

--Phil

Phil Karn
2006-12-31, 00:34
Eric Seaberg wrote:

> I'd really rather NOT re-rip everything with FLAC. I have thought
> about it just to get the extra quality bump, but iTunes won't read them
> which, for me anyway, REALLY puts a crimp in my tag editing and
> organization for SlimServer. As a Mac user, there just aren't as many
> options to work with FLAC yet.

This was a problem for us too until I discovered mt-daapd, an open
source music server (functionally somewhat similar to Slimserver) that
speaks DAAP, Apple's protocol for sharing iTunes collections over a LAN.

I run mt-daapd alongside Slimserver on the Linux box that has our music
library. The clients see iTunes' native file formats (.mp3, .m4a, .m4p,
..wav) unchanged, while non-iTunes formats like .flac and .ogg
automatically appear to iTunes as WAV files.

The two servers coexist nicely. We can now use iTunes/mt-daapd for its
superior search and seeking features and Slimserver for when we want to
play something through a Squeezebox and good speakers.

Unfortunately, DAAP is read-only, so iTunes cannot edit tags on a remote
server.

--Phil

Eric Seaberg
2007-01-10, 13:44
So, there are a couple of CDs that are UNPLAYABLE on SS because of this problem. It's definitely pointing to the call to QuickTime (mov123) and a delay in processing in the first 350ms.

My ONLY way around this is to re-encode from AAC to 320k MP3 using iTunes. I can't get any Mac based FLAC encoder to re-encode the AAC files... some 'wrapper' error comes up.

If anyone has another way to do this I'd sure appreciate it... other than re-ripping my entire library to FLAC. It's just not practical on a Mac until someone gets the TAG options working.


Thanks guys.

(SD, is there a fix for this soon?)

Eric Seaberg
2007-01-10, 14:15
The problem is EXCLUSIVE to AAC files converting to LAME to stream to SB/TP. My ALAC (Apple Lossless) files do NOT have the problem.

SD... can we figure this out, PLEASE?!

DMR NYC
2007-01-10, 15:39
I am not sure that the FLAC problem is the same bug that was discussed before regarding ALAC.

I am one of the people who had clipping of the end of certain tracks. SD support gave me a fix that solved the ALAC problem (in SS 6.5.1) by revamping a file and using an older translator.

Since then, I have decided to switch from Apple lossless to FLAC, and I have had no problems with FLAC whatsoever.

Good luck,

David in NYC

Eric Seaberg
2007-01-10, 19:07
Again, the problem is NOT with LOSSLESS files but with AAC (Apple's own 'better then LAME' concept) that must use QuickTime to convert prior to LAME converting for the server. In most cases, the first 350ms is lost in the conversion, i.e. FIRST NOTE MISSING.

As I've mentioned before, Apple LOSSLESS (ALAC) does not have the problem... and I'm not sure what the difference is since both formats must go through QuickTime to get to FLAC...

SD??!! WHAZZUP??!!

Ben Sandee
2007-01-10, 22:20
On 1/10/07, Eric Seaberg <
Eric.Seaberg.2k84en1168481401 (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
>
> Again, the problem is NOT with LOSSLESS files but with AAC (Apple's own
> 'better then LAME' concept) that must use QuickTime to convert prior to
> LAME converting for the server. In most cases, the first 350ms is lost
> in the conversion, i.e. FIRST NOTE MISSING.
>
> As I've mentioned before, Apple LOSSLESS (ALAC) does not have the
> problem... and I'm not sure what the difference is since both formats
> must go through QuickTime to get to FLAC...


Is it a problem with Apple Lossless files too?

Ben

Eric Seaberg
2007-01-11, 07:57
On 1/10/07,

Is it a problem with Apple Lossless files too?

Ben

OK, I haven't noticed it with ALAC files.

Mark Lanctot
2007-01-11, 08:03
Eric:

I do not intend the following as an insult - this is to help.

This is an informal user support forum. It is not the official means of obtaining Slim Devices/Logitech support. So continuing to insist several times a day on immediate assistance here may or may not help as the developers do not always actively follow every thread on the forum. There's a chance they might, but it's by no means assured.

For basic problems, it's best to contact support at their phone number or using support (at) slimdevices (dot) com. Of course basic problems can also be addressed in this forum.

However you have done some pretty intensive investigation into the problem which should assist the developers in their bug squishing efforts - you have identified an issue which is well beyond basic and it does not appear to be something support can fix without developer assistance. I would suggest you log a bug on http://bugs.slimdevices.com. You'll need to create an account. Bugzilla has mechanisms for assigning a developer, cataloguing, tracking progress, prioritizing, etc. This forum does not.

Not being a developer myself, I can't promise progress on your bug, but properly logging a bug is your best option. This may be a tough bug as it involves a potential problem with Quicktime and Apple will almost surely not help.

Other pointers:

- search for an existing bug first. I looked in this thread, I didn't see a link to one. I also searched bugzilla for "AAC" and didn't find anything relevant to this issue.

- "just the facts". Don't rant on bugzilla. Just present the facts and your findings as complete as you can.

Eric Seaberg
2007-01-11, 13:18
Yeah I have an account there and was going to submit an 'official' request this weekend. Thanks for the kind post!

I stayed home yesterday and had a lot of time to research it more... which is why there are so many posts in one day. I WAS ON A MISSION!!!



Thanks again

Mark Lanctot
2007-01-12, 09:35
When you create it, post the link here so people can vote on it and add to it.

Eric Seaberg
2007-01-12, 21:09
http://bugs.slimdevices.com/show_bug.cgi?id=4662


Vote if you've got this problem. I've discovered it's based on a call to QuickTime to convert AAC files (in my case) to LAME. Some users have noted the same problem with ALAC (Apple Lossless) files as well.


Thanks...