REM File Decoded Size as Length of MP3s in Cue Sheet?

[Dawn_fan]

Hello, I recently created a program to automate writing cue files based on the titles of MP3 files in a given directory. I followed the exact same format as imgburn's cue files and got the program to succeed even without putting in the line of the REM FILE DECODED size for each track: Imgburn could recognize the file and burn the disc with the exact CD text I desired.

My only concern is that now, Imgburn performs 'Analyzing Audio Files' each time I want to burn the image files created with my program. This is opposed to it only doing it once when I create a cue file from Imgburn itself and it won't have to decode each file every time I want to burn that image.

This isn't really a big deal; however, I do burn many copies of an image and having to convert files prior to each burn of the image would be a bit taxing on my computers. (I use older machines for burning.)

I think this is only because I don't specify the REM file decoded size in my custom cue files from my program.

I did some more digging and I saw someone able to do it when they were creating a similar program of writing cue files with python. I personally am using Java for my program and there was no good way of getting the decoded size of an MP3 in MM:SS:FF format.

However, there is an easy way to just get the normal playable length of the MP3 file using java. This leads me to my question of: Can I just use the length of the MP3 file itself as the REM file decoded size?

I also read somewhere that the length should be almost the same and the only difference would be a couple of frames; there are 74 frames in a whole second of audio so I would only be compromising a maximum of a single second in audio? I really wouldn't notice that at all. But I just want to make sure that what I plan to do won't ruin the whole point of a traditional audio CD as opposed to a data CD of MP3s or MP3 CD.

Another general question I had about the way Imgburn works: are these decoded files whenever Imgburn performs the 'Analyzing Audio Files' constructed in memory as the disc burns? I still can't piece my around how I have normal cue files that do not correspond with a binary file of the raw data structure of an audio CD. I feel like I read somewhere on the forum that the files are constructed in small segments in memory as the burn proceeds but I just wanted to confirm.

I apologize for a very long initial post and I thank those who bother reading even a portion of it. Thanks for any help in advance!

[LIGHTNING UK!]

Yes, having that line in the file means ImgBurn doesn't have to run a dummy decode to get the correct output file length from the directshow decoding routine.

MP3 isn't a lossless format anyway, so a few frames here and there probably won't hurt. You'd be using a different format if you really cared about faithfully reproducing the original format (and they came from CD).

The decoding is all done in memory. No intermediate file is ever created. I feed the file into directshow and then just keep asking for the next chunk of output data until it says it has finished decoding.

[Dawn_fan]

On 7/9/2024 at 2:44 AM, LIGHTNING UK! said:

Yes, having that line in the file means ImgBurn doesn't have to run a dummy decode to get the correct output file length from the directshow decoding routine.

Ah ok, that makes sense. So that correct output file size is used to determine where the tracks start and end in terms of sectors? So that's why Imgburn must need that before the burn?

 

On 7/9/2024 at 2:44 AM, LIGHTNING UK! said:

MP3 isn't a lossless format anyway, so a few frames here and there probably won't hurt. You'd be using a different format if you really cared about faithfully reproducing the original format (and they came from CD).

Yeah I figured. After posting, I actually compared the length of tracks in a music player with the file decoded size length that comes in the cue files: the only difference was a couple of frames.

So just to confirm: lets say I have a song that's 3:55 in length but it's length including the frames is 3:55:23. If I compromise on only those 23 frames and put 3:55:00 as the file decoded size in the cue file, I have got nothing to lose right? I just want to make sure the burn will still go through without Imgburn giving an error. (And yeah I don't care at all about those frames, if anything only a single second, that too towards the end of the track, would only be missed.)

On 7/9/2024 at 2:44 AM, LIGHTNING UK! said:

The decoding is all done in memory. No intermediate file is ever created. I feed the file into directshow and then just keep asking for the next chunk of output data until it says it has finished decoding.

I see, that's a fabulous system to use so that our storage won't have to keep on holding the large decoded files. 😄

Thanks for your reply.