Topic: FEATURE REQ : Cue sheet support (Read 5679 times)

hit_ny · « **on:** August 29, 2003, 01:47:20 am »

Is it possible to add cue sheet support to MC for audio files. Am thinking of something along the lines of APL files except for any type of audio file mp3, ogg etc.

MC would parse cue sheets and create corresponding MPL files ( or MCL mediacenterlist) files. This would allow the tracks in albums that were ripped as one big audio file to be entered in the databse and make it transparent to the user wheter they were separate or part a big file. Pretty much like MC makes for a consistent user interface with the audio files it supports curently.
Allowing audio analysis etc as well as library querying.

Another way to do this would be to allow the existing APL files to be used with other formats instead of just APE files. One would run the makeapl utility to create the APL files, and MC would magically recognise the media type the APL file points to and play it. More of a hack, i admit but less work

This has the advantage of leaving mixed/live albums in their mixed format and gets around gapless play problems with formats that dont support it ie mp3.

It is possible to split albums so that they can be used, but this involves doubling disk space if the mixed file is wanted as well. I'm sure lots of people have audio files already ripped this way so transcoding to a better format does not offer any advantages. It would be great if we could use them as is. Lowers the entry barrier and gives another great reason to use MC for everything

So *pretty* PLEASE ..with sugar on top

lets have cue sheet support in MC.

What do people think ?

Tolga · « **Reply #1 on:** August 29, 2003, 02:05:51 am »

I am supporting this

Valissystem · « **Reply #2 on:** August 29, 2003, 02:15:44 am »

Quote

I am supporting this

Yes, so do I.

NoCodeUK · « **Reply #3 on:** August 29, 2003, 03:55:01 am »

Not to put a damper on things as I would definitely support this too but I think it has been suggested before and the answer was no...

Adam

hit_ny · « **Reply #4 on:** August 29, 2003, 05:05:02 am »

Quote

Not to put a damper on things as I would definitely support this too but I think it has been suggested before and the answer was no...

Hmmm....

wonder why ?

i suggested doing it the APL file way so the existing cue files would only be read from rather than be used to save any MC specific data.

Cue sheets are supported already in MC but only for APE ( via MakeAPL).

is the lack of a makeAPL or make MPL utility stopping things ?

Could this makeMPL not be implemented directly in MC itself and fire up, the moment it detects a cue sheet.

phelt · « **Reply #5 on:** August 29, 2003, 05:18:46 am »

Yes, this has been asked for many times by quite a few people, including myself. I'm not sure if the J River folks have philisophical or technical problems with this, or if it just got overlooked or slotted as a low-priority item... It would be another nice feature to distinguish MC from the chumps, IMO

hit_ny · « **Reply #6 on:** August 29, 2003, 06:02:53 am »

Quote

I'm not sure if the J River folks have philisophical or technical problems with this, or if it just got overlooked or slotted as a low-priority item...

lets look at this..

philosophical : let JRiver enlighten us on this.

technical :
1) cue file needs to be understood. My cue files have well defined-fields in them

PERFORMER <-------------Album/Artist
TITLE <------------Album
FILE
TRACK [01-..n] AUDIO <--track#
TITLE <--name
PERFORMER <-artist

these fields are pretty much the same in all my cue files. They are de-limited by quotes " as well.

A problem might arise in a badly formed/incomplete cue file. In which case, MC can either refuse to import it saying the cue sheet failed at such line etc.

If the rules for a well-defined cue sheet are stated, then its just a question of syntax.

2) MPL files
i am wondering if these files need to be created at all. Could MC not calculate the offsets from the time specified in the cue sheet and save it directly in the library. Again if times seem off..it could refuse to import it.

This might be cleaner way of implementing without MPL files cluttering up the dir. Not sure what the performance implications are regarding creating MPL files or no MPL files.

Wonder if i left anything out ? Hopefully the details can be thrashed out here and then we hand JRiver a spec.

overlooked , low priority :
keep bumping this thread up

Markus · « **Reply #7 on:** August 29, 2003, 06:54:13 am »

I am waiting for this for quite a while now, too. It's one of the last reasons to you an additional player.

Rands · « **Reply #8 on:** August 29, 2003, 09:06:20 am »

I've been requesting this since I got MC and I was never told "no." In fact, as far as I know, the request has been ignored.

JimH · « **Reply #9 on:** August 29, 2003, 09:36:53 am »

Quote

I've been requesting this since I got MC and I was never told "no." In fact, as far as I know, the request has been ignored.

We read everything written here. That we don't do something doesn't mean we're ignoring the request. It may just mean we don't think it is a high priority.

Rands · « **Reply #10 on:** August 29, 2003, 12:42:23 pm »

Quote

We read everything written here. That we don't do something doesn't mean we're ignoring the request. It may just mean we don't think it is a high priority.

Sorry, that came out differently than I meant it to. I know that not only do you guys read everything that goes on here, you usually address everything as well. Since it was never addressed, I meant that it was ignored here on the board, not necessarily in MC's future.

Hope that clears up my intent.

hit_ny · « **Reply #11 on:** August 30, 2003, 01:19:26 am »

Quote

I am waiting for this for quite a while now, too. It's one of the last reasons to you an additional player.

Right..but instead of just a track display like winamp+mp3cue plugin, you can have search features as well as audio analysis. want to know what an artist did...type in the search box..and BAM! it all appears.

i admit the MC team has been very responsive for lots of things. The frequent builds are a good sign.

But cue sheet support is a feature that is long overdue and asked for, IMO its the last feature i need to make full use of my audio collection. I wish they had tackled this in version 8 when jukebox was mainly for audio.

i am hoping this feature will appear sooner rather than later, in ver 9 if not 10.

If JRiver decides to go the APL route, Get Ashland, i bet he could figure this out in a jiffy. He made APL possible in the first place, why not extend the idea to other audio files as well !

hit_ny · « **Reply #12 on:** September 03, 2003, 02:44:52 am »

*bump*

rocketsauce · « **Reply #13 on:** September 03, 2003, 03:36:30 am »

Quote

Get Ashland

They already have him.

Rob

hit_ny · « **Reply #14 on:** September 04, 2003, 04:01:25 am »

Quote

They already have him.

thats good news !!

i was thinking about how CUE files could be implemented in MC and came up with 2 approaches.

1) APL Method
MC reads in cue files, parses them and creates corresponding APL files for mp3. Reads APL files and populates the library. Any MC tagging is done in the APL file as is done currently. MC uses offset information stored in the APL file to access the right position.

2) MC reads in cue and stores the data in the library, no APL files are created at all. Any tagging, AA etc is done directly in the library entry. This might require creating an internal (invisible to users) field in the library that contains the offset information to go to the exact position in the big audio file.

This seems to be a cleaner way, also removes the need to create a proprietary file extension ( MPL , MCL etc) that would only be useful in a MC context.

i am partial to either method so long as access is quickest.

What do people think ? which approach is preferable ?

Anything i left out ?

hit_ny · « **Reply #15 on:** September 09, 2003, 01:37:45 pm »

yep, MC for most things except mp3s with cue files. I hope to see CUE sheet support surpass winamp+mp3cue to the point its the same as APL support. Since MC is considered a gapless player, this should not pose any problems. This way all those tracks an be inventoried etc..and even custom playlists made.

i tend to prefer listening to the mixed stuff when i am on long drives, most portable players dont support gapless play. So the only alternative is to rip as one big file. Given the absence of formats other than mp3 on portable players, this is really the only option.

In fact even for gapless formats, ape, ogg, mp4, its still preferable to rip with cue as its guaranteed to be gapless and no problems with whether the player supports it or not.

i dont see cue files going away any time soon. It sure would be great to be able to use stuff that was ripped with CUE files as is, rather than having to chop it up ( thereby having 2 versions of the same album

) cos the player wont support it.

So pls JRiver UP the priority for CUE file support.

dragyn · « **Reply #16 on:** September 09, 2003, 01:41:21 pm »

I've already jumped on them before way back in 2002. JohnT is the CD "guru" so you'd have to get on his case.

ape/apl & cue sheets

hit_ny · « **Reply #17 on:** September 09, 2003, 02:21:17 pm »

Thx for pointing that out dragyn.

Quote

We read everything written here. That we don't do something doesn't mean we're ignoring the request. It may just mean we don't think it is a high priority.

Would lots of users asking for this since almost a year make a difference ?

Where is this man JohnT ?

(j/k)

dragyn · « **Reply #18 on:** September 09, 2003, 02:49:04 pm »

I think he's busy with the new DVD burning in 9.1

What you could do is get a list of everyone that wants it and send it to Jim. Jim (I think) makes all the decisions in MC..or something.

...but don't bother Matt. He becoming grouchy lately and it would be best if you would leave him alone.

jam · « **Reply #19 on:** September 09, 2003, 06:32:49 pm »

I'm supporting this too.

Wish no frame corruption like what MakeAPL has been having now (I hope Matt will fix it sometime near future after the release of MC9.1

).

BTW, just curious, is there any standard to write year/gerne/etc. information in cue files?

hit_ny · « **Reply #20 on:** September 10, 2003, 02:21:03 am »

Quote

Wish no frame corruption like what MakeAPL has been having now (I hope Matt will fix it sometime near future after the release of MC9.1 ).

Can you elaborate a bit more on this ? have not seen anything on the monkey's forum about this.

Quote

BTW, just curious, is there any standard to write year/gerne/etc. information in cue files?

im not sure, do we want MC to write back to cue files ?
or modify them.

Would it be better to store this in the library itself.

Matt · « **Reply #21 on:** September 17, 2003, 07:26:34 am »

This is tricky because the MP3 format doesn't support exact seeking. That means you can't close / reopen the file even when switching tracks. That's a bit of a paradigm shift from how MC works now and too ambitious of a change for v9.1.

We hope to address this with version 10.

Quote

...but don't bother Matt. He becoming grouchy lately and it would be best if you would leave him alone.

Hey kids, get off my lawn!

hit_ny · « **Reply #22 on:** September 17, 2003, 07:43:59 am »

Quote

This is tricky because the MP3 format doesn't support exact seeking. That means you can't close / reopen the file even when switching tracks.

im not an expert on the mp3 format so will humbly submit to your opinion, but was wondering that mp3cue plugin in winamp seems to manage this w/o problems. Its possible to switch between diff tracks in a cue file and there does not seem to be any issues, finding the exact point. In fact it pretty accurate. When listening to mix albums, i notice that new tracks tend to start with a little volume swell, mp3cue reproduces this, leading me to think it found the right spot.

Of course mp3cue does not let you re-order tracks.

Quote

That's a bit of a paradigm shift from how MC works now and too ambitious of a change for v9.1.

We hope to address this with version 10.

Thanks

( am not alone in this ) can't wait, hmmmmm me thinks v10 will be out before this X'mas.

hit_ny · « **Reply #23 on:** September 24, 2003, 12:06:34 pm »

Quote

This is tricky because the MP3 format doesn't support exact seeking. That means you can't close / reopen the file even when switching tracks.

Some more thoughts...

I'm not sure how winamp does it, but you can jump to a certain postion in a track by entering its time etc. If i have other files in addition to the big audio file in the playlist, winamp manages to jump to them sans problem. i can go back to the big one, and mp3cue displays stuff as normal. Does this address what you meant above ?

Is it possible to access an mp3 by converting from time to frames. If you know how long a track is then is there a way to calculate a frame offset for it ?

Mp3cue plugin for winamp, only opens the file once when its selected for play. When the track changes its only the track name display that updates. The file is still playing as is. So to support CUE files would require the playing now file list to update or the track list when the album is clicked on.

i would imagine that during import, if MC detects a cue file it would associate it with the big audio file, in a similar way that cover art images can be associated to a media file. To keep it simple, the cue filename needs to be the same as the audio file. This is the way mp3cue works.

I imagine a structure holding the track data ( got form the cue file), associated with the big audio file stored in the library.

I am undecided on whether its better to store stuff in the library or use an intermediate stage like you have for APL files. On one hand any modifcations are done on the intermediate step ie the APL file, leaving the cue file unmodified. I thought of skipping the APL stage and going directly into the library.

Now that i think of it, its a tricky problem, but not impossible. Would defnitely set MC apart from the rest.

INTERACT FORUM

Author Topic: FEATURE REQ : Cue sheet support (Read 5679 times)

phelt

dragyn

dragyn