Print

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

[GHammer]

In MC 11, CUE file playback support was introduced. Which is nice as far as it goes.

The CUE file support though needs extended/finished.

Tagging is not possible with a CUE entry, for example, but there are other functions for selections/files that do not work.

It has been mentioned that extending APL to work with all audio files would solve a host of issues people are interested in.

Such as creating 'virtual albums' built from various audio files. Or eliminating duplicate files between "Greatest Hits" by allowing a pointer to a single audio file to be the 'selection' in many albums.

In retrospect, I'd say the APL idea is best. If this is done there would need to be a way to create APL files in MC too.

Doing this would give us a taggable item that can also be moved and backed up when we want.

Thanks for listening.

[Rands]

I agree with this although I think some people might complain that it's not standard.  CUE files have been the standard in this for quite some time so if J River went with this, I'd like to see them maintain CUE support as well.

[GHammer]

I agree with this although I think some people might complain that it's not standard.  CUE files have been the standard in this for quite some time so if J River went with this, I'd like to see them maintain CUE support as well.

Progress.

Somebody's gotta start a new method. Why not MC and the guy that created APL files to begin with?

[hit_ny]

I agree with this although I think some people might complain that it's not standard.  CUE files have been the standard in this for quite some time so if J River went with this, I'd like to see them maintain CUE support as well.

Cue file ability will be retained.

Using APLs for non APE media is what is being requested here. The idea comes from FB2K having no problems at all in dealing with APL files pointing to non-APE files. This opens up new possibilities given MC's powerful database.

I'm curious about one thing though.
- Lets say you have an APE file and make the corresponding APLS of it and then drop these APLS in a different location.
- Import  APLs into MC .
- Now move the APE file from within MC to a differnent location.

If you play the APL files, do they still play or has MC lost track of where the APE file is ?

[GHammer]

Cue file ability will be retained.

Using APLs for non APE media is what is being requested here. The idea comes from FB2K having no problems at all in dealing with APL files pointing to non-APE files. This opens up new possibilities given MC's powerful database.

I'm curious about one thing though.
- Lets say you have an APE file and make the corresponding APLS of it and then drop these APLS in a different location.
- Import  APLs into MC .
- Now move the APE file from within MC to a differnent location.

If you play the APL files, do they still play or has MC lost track of where the APE file is ?

Nope they'd be broken.

And in the first instance, they'd be broken.

Maybe a way to create a subtrack.

Blah, blah, blah.
Track 1

You could also reference it as Blah Greatest, Track 27

But then you lose the image, tagging ability, etc you get with an APL.

[cfgreen]

[Nope they'd be broken.

And in the first instance, they'd be broken.

Maybe a way to create a subtrack./quote]

You can edit the path in the APL (But it is a pain). Then you run into the problem of moving the files also

[GHammer]

Edit the path in an APL?
How?

[hit_ny]

Hmm...are you saying that an APL referencing a file cannot exist if the APE file is not in the same directory as the APLs ?

Another test for this type of behavior ..is if you add image from file or associate cover art for the album tracks. Now if you move the album elsewhere so that the image path specified previously, is invalid.  I think MC is unable to correct the image path.

[GHammer]

Hmm...are you saying that an APL referencing a file cannot exist if the APE file is not in the same directory as the APLs ?

Another test for this type of behavior ..is if you add image from file or associate cover art for the album tracks. Now if you move the album elsewhere so that the image path specified previously, is invalid.  I think MC is unable to correct the image path.

I won't say 100% because I'm not gonna look at every APL on my system.

The ones I have looked at do not show a path, just the target APL name.

So, if you move the APL it would no longer find the APE it links with.

[hit_ny]

I won't say 100% because I'm not gonna look at every APL on my system.

The ones I have looked at do not show a path, just the target APL name.

So, if you move the APL it would no longer find the APE it links with.

Ahhh   i fear we may not be able to use APL files to refer to files that are not in the same directory as APL assumes that APE must be in the same path.

Of course if Matt were to allow this, everything is possible

[Alex B]

Ahhh i fear we may not be able to use APL files to refer to files that are not in the same directory as APL assumes that APE must be in the same path.

There is no need to fear. 

Just make a cue file with a filename containing a full path. Unfortunately MakeAPL trims the path out when making APLs. That leaves us FB2k and it can indeed make APL files with the whole path. If the APLs point to an APE file you can use them in MC without problems.

I will write more about this later on today. Just now I have to do some other things... like work 

[hit_ny]

There is no need to fear. 

Just make a cue file with a filename containing a full path. Unfortunately MakeAPL trims the path out when making APLs. That leaves us FB2k and it can indeed make APL files with the whole path. If the APLs point to an APE file you can use them in MC without problems.

I will write more about this later on today. Just now I have to do some other things... like work 

Well spotted Alex, i guess if MC did the same , this is workable.

However i think its better that cue files retain the current format, ie file name only rather than path as well. Am not sure if it would break things otherwise.

Its the APLs that need the path and MC can get this from the album dir.

Will APLs with path included, work on APE capable media players other than FB2K ?

[GHammer]

Will APLs with path included, work on APE capable media players other than FB2K ?

How many are there?

[hit_ny]

However i think its better that cue files retain the current format, ie file name only rather than path as well. Am not sure if it would break things otherwise.

Its the APLs that need the path and MC can get this from the album dir.

Argh...just thought of something.

If the APLs have path info in them it would be invalid if burnt to a CD or copied elsewhere. As the APLs would only reflect where the media files reside on the host system.

Do ppl see what i'm geting at ?

[GHammer]

Argh...just thought of something.

If the APLs have path info in them it would be invalid if burnt to a CD or copied elsewhere. As the APLs would only reflect where the media files reside on the host system.

Do ppl see what i'm geting at ?

If you want to have 'virtual' selections, there is going to have to be a way to associate the pointer with the target file.

I have no player, save my computer, that can use APL/APE files. The two players I use handle an APL having a path in them.

Would that path need updated if the APE was moved? Yes. Could it be done? Yes. Is it worth the pain of development? Well...

I think so, but I have a need/desire for this. I think it would be one more unique cool thing that MC does.

I can also see though that the maintenance of it would be intensive if the capability were used greatly.

Example
I have a single APE. I create entries for 10-20 'selections' from it using APL files.
MC keeps the path info for everything in its library.
I move the APE.
MC has to find that it was moved, then find all files the reference it, then update all those files.

Impossible? Naaah. Hard? Maybe, I don't know.

[Alex B]

At first, thanks GH. You summarized it well in your opening post.

Here are links to some of the previous threads for those who are unfamiliar with this matter:

Duplicates; 14.1.2005
APL support could be better; December 15, 2004
Playlists among albums; August 26, 2004
Cue file support in MC; August 24, 2004
Search for and eliminate duplicates?; July 26, 2004

About the same thing was discussed 18 months ago:
Virtual Albums?; June 6, 2003


As Matt has previously stated the sample accurate seeking was the toughest part in creating CUE support. That part MC already has and it can be used with MP3/OGG/WMA/MPC APL files.

The rest is normal file handling routine for MC and should be a piece of cake.

The link part of an APL is a simple text file:

[Monkey's Audio Image Link File]
Image File=APLtest.ape
Start Block=1067220
Finish Block=1367100

It is quite possible to save that with Notepad, rename it to .apl and use it in MC or even add a path:

[Monkey's Audio Image Link File]
Image File=E:\test\APLtoolsTEST\Path\APLtest.ape
Start Block=1067220
Finish Block=1367100

When the file is tagged it includes an APE v.2 tag:

[Monkey's Audio Image Link File]
Image File=E:\test\APLtoolsTEST\Path\APLtest.ape
Start Block=1067220
Finish Block=1367100

----- APE TAG (DO NOT TOUCH!!!) -----
APETAGEXР ¾                          Track 3        Genre Other       Artist Art Apl        Title A Song          Album Testimony        TOOL VERSION 11.0.177
       TOOL NAME Media CenterAPETAGEXР ¾         €       

An APE v.2 tag includes binary code and the tag part gets broken if the filename path is edited with Notepad, but MC can still read the link part of the file and rewrite the tags if the information is in the library.

What we need here is a new library field: [APL link]. It would read and write the filename path from/to APL files. It should also be editable.

EDIT

The library field content would look like this: "E:\test\APLtoolsTEST\Path\APLtest.ape" or "E:\test\APLtoolsTEST\Path\APLtest.mp3" if the main file is an MP3 file. It would look and behave just like a standard [Filename] field.

[hit_ny]

If you want to have 'virtual' selections, there is going to have to be a way to associate the pointer with the target file.

Agreed, question is where is this path stored ? in the file, in the library or both. I would like the option to save the path to the file, as this will make subsequent import in the event of library corruption easier.

If one burns an Audio-CD with APLs, its understood that its the pointed to file(s) that should be burned, if its a data CD, i'm inclined to think likewise.

If an attempt is made to delete the linked to file, i would like a warning to popup, indicating how many links are present.

What we need here is a new library field: [APL link]. It would read and write the filename path from/to APL files. It should also be editable.

i like this idea.

[GHammer]

Agreed, question is where is this path stored ? in the file, in the library or both. I would like the option to save the path to the file, as this will make subsequent import in the event of library corruption easier.

If one burns an Audio-CD with APLs, its understood that its the pointed to file(s) that should be burned, if its a data CD, i'm inclined to think likewise.

If an attempt is made to delete the linked to file, i would like a warning to popup, indicating how many links are present.



i like this idea.

I'd think that the library should be the first place that MC looked for the linked file info. If it did not find it there, then read the APL to find its target.

I still do not know why I'd be writing APE files to a CD.

I agree, if 'virtual' entries are allowed then you need warned when the target is moving/deleted/whatever. Should the 'virtual' entries be deleted too when the target is deleted? Kinda useless at that point, eh?

[Alex B]

I'd think that the library should be the first place that MC looked for the linked file info. If it did not find it there, then read the APL to find its target.

I agree, if 'virtual' entries are allowed then you need warned when the target is moving/deleted/whatever. Should the 'virtual' entries be deleted too when the target is deleted? Kinda useless at that point, eh?

Let's see what happens. I would first like to have support for the other compression formats in APL. The editable link path has been on my personal wish list a long time before I even thought that APL files could be used for virtual linking or for other compression formats. From time to time I have had reasons to rename my main APE files.

I still do not know why I'd be writing APE files to a CD.

Neither do I. I burn only Audio and MP3 CDs with MC. They are meant only for listening.

For data backups on CD-R/RW or DVD-R/RW I would use a dedicated burning program, e.g. Nero. Then I would include everything.

[GHammer]

I agree. But when CUE support was added, I think those who had asked were not clear in what they were looking for. Once the time was spent on it initially, it hasn't been revisited. Understandable, lots of other things going on in MC.

So, I'd just like to set out some things those who want this feature would like to have it be. Then if it is added it can be fairly complete.

Most of what has been suggested doesn't look overly difficult (from this side of the process!). The tracking of links may be a sticky wicket. But, the new database would seem suited for just that sort of thing.

[GHammer]

Just getting this back in view.
Haven't seen anything done on CUE files or regarding extending APLs in a few months.

[hit_ny]

Ditto

[GHammer]

Now that Matt is the King of making Canadian bacon and pineapple sandwiches, maybe he can take a look at these problems and ideas.

[GHammer]

In view again. It's a miracle!
Threads brought back from the dead!!










No animals were hurt during this process.

[hit_ny]

Heh yeah... i guess we need to remind them again when they start v12 in June. That and to finish up CUE files once and for all

[GHammer]

Heh yeah... i guess we need to remind them again when they start v12 in June. That and to finish up CUE files once and for all

V12 will have to have some audio focus or I won't be playing along.

I understand that it is a Media Center.
For my 10 cents, with the exception of the very minimal CUE support, there is not much in 11 that I'm that interested in. I don't do videos, don't network, and the handheld support to shares/removables has only worked intermittently. The CUE file support was the sole reason for me to get 11 and it went nowhere.

[Alex B]

Just my two cents, but I would actually like to see version 11.1 next. It could have only the few remaining loose ends fixed (like this CUE/APL issue) and some tweaking done here and there.

By the way, have you noticed that the heavyweights in SW business rarely have big version numbers like over 10? For some reason, they tend to rename their products instead. Personally I would rather like to see continuity. If a well-known product has good reputation a big version number like 15 or 20 should only strengthen the good name.