Print

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

[GHammer]

With all the work being done on v11, it would seem to be a good time to include cue file support. I wouldn't think it's that hard, but you could always ask the foobar developer how to do it if you get stuck. Or XMPlay folks have it working, ask there. There are others.

Or, let those of us who have requested this know that you simply don't care to do it.

[Matt]

"CUE file support" could apply to ripping, burning, or playback.

In any event, all of them are on the table to be included in MC someday.

[hit_ny]

Ahh one of my favorite subjects

The problem with mp3 is that it does not allow seeks to be made given a seek position. And a cue file is just that, a list of tracks with seek positions.

Now other players (winamp+mp3 cue) and FB2K get around this by actually parsing the file from the beginning as its not possible with mp3 to directly jump to the point stated in the cue. FB2K is sample accurate, wimamp cheats/guesses so it appears faster at seeking but in reality it does not get it exactly right.

I would prefer that MC (if they decide to implement CUE) be sample exact. This brings a slight hit in seek performance (can be a fraction of a second to a whole second) but it would allow accurate Audio analysis and can take advantage of the ever powerful library.

I use FB2K for albums with cues currently, it works pretty well and has a light Album list function and makes direct edits the cue files. But i would prefer to do this in MC as FB2K is not as easy to mass tag (especially tracks in a cue)

Another idea i have heard to get around the mp3 seek problem is to wrap an mp3 in a mp4. mp4 supposedly has seek tables that will allow sample exact seeking. I tried this out in FB2k but found the performance only slightly better to the actual mp3 itself. So am not sure whether its worth doing.

[Valissystem]

Ahh one of my favorite subjects

Ahh this one. So I am guessing we are all talking about playing.

The difficult part of cue files, are they can refer to any of a number of  file types for the actual data - mp3, wav, ape, flac etc.

I quite like the APL file concept, where you have a specific file that can have information about where in a file a particular track is found. Now of course where APL files are supposed to be APE files they point to, as fb2k for instance implement it, they can used for other audio data types.

If not an actual APL file, then perhaps a similar file format could be useful - almost an "anti-playlist" file format! Any other comments!

[hit_ny]

If not an actual APL file, then perhaps a similar file format could be useful - almost an "anti-playlist" file format! Any other comments!

I thought about this in the beginning wrt to mp3 files playback, since that's were my use of cue is. It appears to me after playing with FB2K, there is no need for APL with mp3 or any other media for that matter. FB2K can use just the mp3 and the cue or any media+cue because it has a database that understands cue files.

APL is good if used with a standalone player that lacks a library/database that can understand cue, so individual track information (+ any AA) is stored in APL. APL represents an individual track from a big APE file.

With mp3 or other media, could AA information be stored in the CUE enclosed with appropriate comments ?  

So one could pick a track out of an album in the library and queue it in a playlist, MC would understand its start & end from a cue, and read up to the track start position and play it. This probably would require modifying the various decoders to understand that a track from a cue has been requested rather than an individual track.

If MC can understand cue files, does it follow that  APL is redundant ?

[GHammer]

"CUE file support" could apply to ripping, burning, or playback.

In any event, all of them are on the table to be included in MC someday.

Howdy Matt.

Thanks for the reply, with all due respect, that is the answer given for quite some time now.

As for where it could apply, how about in reverse order? Playback, then burning/conversion, then ripping to a single file.

[GHammer]

If not an actual APL file, then perhaps a similar file format could be useful - almost an "anti-playlist" file format! Any other comments!

I thought about this in the beginning wrt to mp3 files playback, since that's were my use of cue is. It appears to me after playing with FB2K, there is no need for APL with mp3 or any other media for that matter. FB2K can use just the mp3 and the cue or any media+cue because it has a database that understands cue files.

APL is good if used with a standalone player that lacks a library/database that can understand cue, so individual track information (+ any AA) is stored in APL. APL represents an individual track from a big APE file.

With mp3 or other media, could AA information be stored in the CUE enclosed with appropriate comments ?  

So one could pick a track out of an album in the library and queue it in a playlist, MC would understand its start & end from a cue, and read up to the track start position and play it. This probably would require modifying the various decoders to understand that a track from a cue has been requested rather than an individual track.

If MC can understand cue files, does it follow that  APL is redundant ?

It would not to me. I use APLs mostly because I want the 'selection' ability that APLs give me.  I see no way to add one selection from a CUE to a playlist for example.

As for tagging, foobar just uses remarks to record it replaygain info in the CUE file. I'd imagine that method could be used to point to cover art, etc.

[JimH]

How about starting a poll to see how many people want cue file support?

[bvm]

As for where it could apply, how about in reverse order? Playback, then burning/conversion, then ripping to a single file.

For me, ripping is #1.  I have lots of classical CDs that have track points that in the olden days would have been index points (except almost nobody supports those any more).  It's more important for me to be able to rip those consecutive tracks into a single uninterrupted mp3 file than it is to be able to jump to those index points.

I only bought MC10 because it sounded like cues were going to be supported...

Me, too, more or less (I also bought it for iPod improvements, not all of which have happened yet).  It's disappointing that they've stopped MC10 development so soon.

[lalittle]

Is there any way that this could be made to work with iPods?  I'd like cue support for MC, but what I'd REALLY like is a way to get gapless playback on the iPod, which at the moment is apparently not possible with any format.

Larry

[hit_ny]

Is there any way that this could be made to work with iPods?  I'd like cue support for MC, but what I'd REALLY like is a way to get gapless playback on the iPod, which at the moment is apparently not possible with any format.

Larry

This really is an Ipod issue, i googled around and found this. Interesting read.

It would not to me. I use APLs mostly because I want the 'selection' ability that APLs give me.  I see no way to add one selection from a CUE to a playlist for example.

As for tagging, foobar just uses remarks to record it replaygain info in the CUE file. I'd imagine that method could be used to point to cover art, etc.

Think of it this way, if MC can understand cues. you would just right click a track in the library and Send to (anywhere). Its possible to do this with FB2K right now. Of course MC supports APLs as many people would have created them but i'm saying APL wont be needed when playing in a "cue friendly" MC.

For me, ripping is #1.  I have lots of classical CDs that have track points that in the olden days would have been index points (except almost nobody supports those any more).  It's more important for me to be able to rip those consecutive tracks into a single uninterrupted mp3 file than it is to be able to jump to those index points.

You could use EAC for ripping to cue. Ripping seems like a lesser issue as there are alternatives around compared to playback that could take advantage of MC's awesome library. Having said that ripping to cue in MC could be implemented easier than playback.

But it does beg the question if i can rip to cue in MC, why can't MC consequently understand it

[lalittle]

This really is an Ipod issue, i googled around and found this. Interesting read.

I keep reading back and forth arguments about whether or not this is an mp3 issue or a player issue, but the one thing that IS for sure is that when it comes to wave files, it absolutely is an iPod issue.

Larry

[GHammer]

How about starting a poll to see how many people want cue file support?

Good idea!

I'll put my money on "At least as many as wanted pong".

See new poll thread.