Print

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

[Cheburashka]

I hope handling of cue files is one of the areas they focus on.  Having a few really screws MC up.  Tag updates fail (the cue file should be updated), iPod synch's fail, and there's no apparent way to extract individual songs.

[lalittle]

I hope handling of cue files is one of the areas they focus on.  Having a few really screws MC up.  Tag updates fail (the cue file should be updated), iPod synch's fail

iPods don't support cue files, so wouldn't this be an iPod issue and not an MC issue?

Thanks,

Larry

[Cheburashka]

iPods don't support cue files, so wouldn't this be an iPod issue and not an MC issue?

Thanks,

Larry

I don't understand that logic.  The problem isn't that the iPod doesn't understand a downloaded cue file.  The problem is that MC, when it tries to transfer a song that it got from an mp3/cue combination, tries to transfer the entire large mp3 file instead of just the part referenced from the cue.

Put another way, MC's convert-if-necessary feature, which is supposed to resolve all these format issues when synching an iPod, doesn't handle cue files.

[hit_ny]

I would defnitely hope they improve cue file handling, my biggest gripe with the current system is that it's not possible to move cue albums in the tree without the cue items getting automatically updated as well.

Updating the cue files for typos from MC etc would also be a big help.

[lalittle]

Put another way, MC's convert-if-necessary feature, which is supposed to resolve all these format issues when synching an iPod, doesn't handle cue files.

That actually occured to me after I responded -- i.e. that converting cue files into seperate mp3s might fall into the "convert if necessary" arena.   I agree that this could make sense, but at the same time, isn't the point of cue files to remove gaps, and wouldn't you want the the gaps removed on the iPod as well?  This begs the question of whether you'd want cue files seperated into individual files on the iPod, or left as one big file.  It seems like there is no uninversally "correct" way of handling this situation.

On a related note, just out of curiosity, what are the current advantages of making mp3 cue files now that mp3 playback in MC is gapless?  It seems like the recent addition of gapless mp3 playback in MC eliminates the reason (or at least the "primary" reason) for using cue files in the first place.

Thanks,

Larry

[tcman41]

What's wrong with both, most beta's are worked on while the original version is still out there being supported. That is kind of the whole concept behind a beta.

TC

[lalittle]

What's wrong with both, most beta's are worked on while the original version is still out there being supported. That is kind of the whole concept behind a beta.

It takes resources.  This isn't a big deal in a huge company where an entire seperate staff is hired to start working on the new version, but with a smaller company where the same people are used for all the developement, it takes resources away from working on the issues that need addressing on the current version.  This means that it will take that much longer for problems to be resolved, making the people who are effected by these issues have to wait longer for resolutions.

Once the "issues" are reduced to a certain point, it makes sense to do as you say and start developing a new version while the current version is still being actively supported as well, but in my opinion we're simply not at that point yet.

Larry

[hit_ny]

CUE gives you perfect gapless...lame headers get you close. Since MC supports CUE anyway, its preferable. lame headers is another option.

[Cheburashka]

I agree that this could make sense, but at the same time, isn't the point of cue files to remove gaps, and wouldn't you want the the gaps removed on the iPod as well?  This begs the question of whether you'd want cue files seperated into individual files on the iPod, or left as one big file.  It seems like there is no uninversally "correct" way of handling this situation.

Well, no, there is a universally correct way of handling it.

If only some songs from the cue are set to synch, then only those songs should be copied over, and not the whole mp3.  Since the iPod won't support cue files, even if all songs are set to synch, they should be extracted, have appropriate gapless tags added, and be copied to the iPod as individual files.

I don't see what's not obvious about this?

[Cheburashka]

That's also only part of it; the other part is the tagging.  Now, if you tag (even accidentally) your whole-album-mp3s, MC gives you an error for each song. 

It should either a) Put the tag information into the cue file, or b) For information it can't put in the cue file, be smart enough not to try and tag the file.

[hit_ny]

Since the iPod won't support cue files, even if all songs are set to synch, they should be extracted, have appropriate gapless tags added, and be copied to the iPod as individual files.

Does the iPod support the gapless lame headers ?

[lalittle]

Well, no, there is a universally correct way of handling it.

If only some songs from the cue are set to synch, then only those songs should be copied over, and not the whole mp3.  Since the iPod won't support cue files, even if all songs are set to synch, they should be extracted, have appropriate gapless tags added, and be copied to the iPod as individual files.

I don't see what's not obvious about this?

The issue that makes this "not obvious" is the fact that the ONLY way to achieve gapless playback on an iPod is to use a single, large file (since iPods do not support the lame mp3 gapless feature.)  Therefore, when you transfer a large cue file to your iPod, there are two different approaches to take.  One is to transfer the entire, large mp3 as one file in order to achieve gapless playback.  This, however, would mean NOT having the ability to access individual songs on the album -- the entire album would be a single "song" to the iPod.  This would also not be desireable to people who like to shuffle songs since the entire album would play.

This leads to the SECOND approach, which would be to split the large mp3 into multiple individual songs, allowing both easy access and shuffling capability instead of gapless playback.

Depending on each person's specific needs, each of these approaches is a valid alternative.  There is no "single approach" that would satisfy everybody -- you have your choice of gapless playback, or better "shuffle" behavior.

Larry

[lalittle]

Does the iPod support the gapless lame headers ?

No.  The iPod is unable to achieve gapless playback between songs of ANY type.  The ONLY way to achieve gapless playback on an iPod (at this time) is to use a single, large file containing the entire album.

Larry

[hit_ny]

I doubt it's technically possible to squeeze in gapless lame headers into a select amount of extracted cue tracks, unless a re-encode is done.

[Alex B]

That's also only part of it; the other part is the tagging. Now, if you tag (even accidentally) your whole-album-mp3s, MC gives you an error for each song.

It should either a) Put the tag information into the cue file, or b) For information it can't put in the cue file, be smart enough not to try and tag the file.

MC reads track info from the cue files but it does not actually import the cue files or keep them connected with the library tracks. The imported cue tracks exist only virtually. MC should know that there are no physical files for storing the tags, but it does not. For example, MC does not try to tag wave or video files. It should behave similarly with cue tracks. I think the problem is partly related to the fact that cue tracks don't have a separate file type. MC shows the file type of the main file instead.

Before any larger-scale cue track tagging I always have to turn file tagging off in the general options.

APL link file support for various file types (besides Monkey's audio) has been requested as a solution for cue problems.

[Alex B]

I doubt it's technically possible to squeeze in gapless lame headers into a select amount of extracted cue tracks, unless a re-encode is done.

You are correct. It is not possible without transcoding. The only way to get that info is to encode the files with LAME.

[hit_ny]

Turning off, update tags in options is the reason i have it in my toolbar for cue tagging sessions. I think MC should not need this. However i like the way MC treats cue items as virtual. I think this is a more neater apprach than using APL files.

[Alex B]

No.  The iPod is unable to achieve gapless playback between songs of ANY type.  The ONLY way to achieve gapless playback on an iPod (at this time) is to use a single, large file containing the entire album.

Larry

I have imported the CD image files besides the cue tracks. When I make MP3 CDs for my car and portable CD players I usually include the big CD image files if the album happens to be in the mp3 + cue format and needs gapless playback. The other way is to use mp3DirectCut or a similar tool and cut the mp3 file before burning the CDs (but just like iPod and most other portables, my CD players cannot play MP3 files gaplessly).

[Alex B]

Turning off, update tags in options is the reason i have it in my toolbar for cue tagging sessions. I think MC should not need this. However i like the way MC treats cue items as virtual. I think this is a more neater apprach than using APL files.

I think APL files would be the easiest way to resolve the file conversion & tagging, CD burning and server problems that cue tracks have now. Also, moving tagged cue tracks to other computers would be much easier. As I have said several times, in my opinion cue track support would fine as it is now if the incorrect tagging warning could be removed. APL files would be needed for making the additional functions to work properly.

[hit_ny]

Isn't most APL info already stored in library fields for a CUE item ?
MC does not use it atm but that could change

[hit_ny]

The other point about saving back to the cue file is its desirable to have the usual fields saved back but not fields like RG, last played, # of plays, custom tags etc (clutters up the CUE file) even tho, they are desirable in usual files.

[lalittle]

CUE gives you perfect gapless...lame headers get you close. Since MC supports CUE anyway, its preferable. lame headers is another option.

The first builds of MC supporting the gapless lame tag info produced some pops, but have you played with the latest MC version?  My tests so far show that it's better than "close" -- the gapless mp3 playback in MC is actually VERY clean now.  I have yet to hear a pop in the tests I've done -- even in quiet passages listening on headphones.  It works amazingly well -- better than I would have expected.

That said, I fully agree that having BOTH options is the best solution since it serves each individual's specific needs.  I just wanted to mention this since you "might" find that the gapless mp3 playback serves the purpose that previously was only solved with cue files.

Larry

[Cheburashka]

You are correct. It is not possible without transcoding. The only way to get that info is to encode the files with LAME.

Why can't you copy the relevant frames out into a new file and add a new header? 

Maybe there's a terminology issue here; it seems to me, at least, that it shouldn't be necessary to resample the file (degrading its quality).

[Cheburashka]

I think its important to separate some issues that we're talking about here.

One of those issues is gapless playback - how MC should support it, how it should be handled when copying to iTunes.

But that's a distinct issue from the handling of cue-linked files.  Whether it's a good idea or not to have cue-linked files for reasons other than gapless playback, the fact is they exist.  Its a fait accompli.  And the question is how MC should handle them.

I have no position on the APL-file vs. cue file vs. library issue (although I'm inclined to having MC update the cue files, for consistency of interface).  It really doesn't matter much.  What DOES matter is that one part of MC (tag updating) shouldn't be confused about what the other part of MC (cue importing) is doing.

The other part of cue handling (that I'm aware of at the moment) is copying files to an iPod. 

Let's put the gapless issue to the side for the minute - iPod gapless support is limited, so it really is a side issue.

I think its pretty obvious how MC should handle this:  The songs should be extracted and copied over separately ("convert if necessary").  If ALL the songs in the cue are set to transfer then, perhaps, the behavior should be different. 

But at the moment, MC simply crunches when it finds a song from a cue in the synch list.  And that's not OK.

[okanet]

I have another question about CUE files.

If I import a folder with an original long file and CUE file, MC imports both in to the library. But when I want to listen that album, MC adds to Playing Now long file too.

By now, I simply remove from library long files after importing, but in that case I have problems burning or copying such albums.

Is there any solution? Thanks.

[Alex B]

If I import a folder with an original long file and CUE file, MC imports both in to the library. But when I want to listen that album, MC adds to Playing Now long file too.

By now, I simply remove from library long files after importing, but in that case I have problems burning or copying such albums.

You can make a custom field that contains additional info. After that you can make separate view schemes for including and excluding the audio source files.

I have posted screenshots of my custom "cue" field here: http://yabb.jriver.com/interact/index.php?topic=25695.msg178377#msg178377.

[hit_ny]

My tests so far show that it's better than "close" -- the gapless mp3 playback in MC is actually VERY clean now.

Acid test, use disk writer to output playback of seperate tracks to a wav file and compare with the cd ripped as one big file. If this LAME solution is truely gapless there should not be any difference. Much more accurate than listening.

[Alex B]

Acid test, use disk writer to output playback of seperate tracks to a wav file and compare with the cd ripped as one big file. If this LAME solution is truely gapless there should not be any difference. Much more accurate than listening.

I don't think it can be bit perfect.

For example, since LAME uses a bit reservoir system a disc image file can have frame data spread over two mp3 frames just on the track boundaries (and most likely has if the album has seamless track changes). The separate track files cannot use bit reservoir on the track boundaries.

Also, the compression system monitors constantly the following audio frames and adjusts several encoding factors accordingly even if the bit reservoir is not used. The end of the file is handled differently than a continuous passage.

However, I think it can be audibly transparent.

[hit_ny]

OK, i guess it gets into the same lossless vs. lossy encoding debate, If you can't hear the difference does it matter 

Don't get me wrong, gapless lame header capabilty is certainly a very welcome addtion, one that i think might be easier to adopt in portable players than CUE.

[hit_ny]

Thinking about what you said Alex, the output is WAV in both cases...bit reservoirs might be different between sep tracks compared to a big file,

is this enough to affect the wav..on which the test is being done ?