File Information

[cmanL]

Is there a C/C++ library function that can retrieve the "bit rate" of a mp3 file? I know that there is a function:

int stat ( const char * pathname , struct stat * statbuf ) ;

for getting file information , but I don't know of a function that can do this. Thanks for any information...

[jpollard]

You can try the "file" command. It may give you what you want.

The problem is that MP3 data isn't a kernel datum - so no base libraries can provide that. The library function would have to read the beginning of the file to decode it.

That said, some part of the SDL library should be able to get that information (http://www.libsdl.org/). SDL should be installed (the various page names are: SDL, SDL-devel, SDL_image, SDL_mixer, and SDL_ttf), so for linking you may need the SDL-devel package.

[ocratato]

A little googling brought up references to libmad, which from looking at mad.h would appear to be able to ascertain the bitrate of an MP3 file.

yum install libmad-devel

should get you going, but it does not appear to be a very friendly library.

[RupertPupkin]

You could try installing the libmpg123-devel package, which has ways of retrieving the average and variable bitrates.

[cmanL]

Thanks for all the information! Is it possible to calculate the size of a resulting .iso file from the data used to create the image ( I'm using mkisofs to make the image ) ? Thanks for any information!

[ocratato]

Originally Posted by cmanL

Thanks for all the information! Is it possible to calculate the size of a resulting .iso file from the data used to create the image ( I'm using mkisofs to make the image ) ? Thanks for any information!

You could try just asking mkisofs. The print-size option does what you need.
Please try to read the man pages first.

(The actual calculation will be complicated by block sizes and other issues that mkisofs handles, so best to let it do the work.)

[jpollard]

It depends on how accurate you need the result.

One rough way is to sum the sizes of all the files then add 10%.

A better way is to use "mkisofs -R -q -print-size <directory>" which will make a pass over the data and tell you how large. This can take nearly as long as it takes to create the ISO in the first place, but can be useful if you are short of workspace.

[cmanL]

Thanks for the information! I've been writing a little "front end" for cdRecord ( just something that gathers the links for music and data to be burned onto the disk , converts formats if necessary , calculates the resulting total music track time , and data iso size for multiple session disk , ect... ). Anyway , the calculations seem to go pretty well but when the program tries to burn a disk with something like 790mb of data some extra data is added to the total ( padding ? ). The situation is like this for 790 mb of prepared data:

Track 01: data    59 MB        
Track 02: audio   53 MB (05:16.47) no preemp pad      pregapsize: 255
Track 03: audio   51 MB (05:05.84) no preemp pad     
Track 04: audio   59 MB (05:52.65) no preemp pad     
Track 05: audio   59 MB (05:51.13) no preemp pad     
Track 06: audio   36 MB (03:36.26) no preemp pad     
Track 07: audio   28 MB (02:51.83) no preemp pad     
Track 08: audio   42 MB (04:12.21) no preemp pad     
Track 09: audio   43 MB (04:20.28) no preemp pad     
Track 10: audio   54 MB (05:23.26) no preemp pad     
Track 11: audio   12 MB (01:16.95) no preemp pad     
Track 12: audio    5 MB (00:33.56) no preemp pad     
Track 13: audio   44 MB (04:27.23) no preemp pad     
Track 14: audio   41 MB (04:09.62) no preemp pad     
Track 15: audio   98 MB (09:44.51) no preemp pad     
Track 16: audio   34 MB (03:25.94) no preemp pad     
Track 17: audio   49 MB (04:52.64) no preemp pad     
Track 18: audio    1 MB (00:07.41) no preemp pad     
Track 19: audio   22 MB (02:14.47) no preemp pad     
Total size:      815 MB (80:48.81) = 363661 sectors
Lout start:      816 MB (80:50/61) = 363661 sectors

Is there a way to calculate the difference in the two data amounts? What accounts for the difference? Thanks for any information!

[jpollard]

Each audio track is supposed to have 2 seconds of null data. Padding involves the filling out of a partial data block.

790 MB is a bit more than what should be on a CD (650–870MB depending on the exact CDR and the media). Normal limits are 650MB (should always fit) as data expands a bit when recorded to CD.

[cmanL]

Ok , thanks for the information! I've been burning disks using about 791 mb ( if I'm interpreting the information correctly from cdRecord ! ) . Anyway , the output of my burner front end gives me this information:

total seconds 4446.07
total minutes 74:06.07132
total iso estimate 43.5586 MB
Stats just using file sizes ******************* 
Wave Total Music 747.955
Wave And Data Total Disk Use 791.513
Wave Total Disk Use 98.9391%

and cdRecord gives me this information when the disk is burned:

FIFO size      : 16777216 = 16384 KB
Track 01: data    42 MB        
Track 02: audio   14 MB (01:26.04) no preemp pad      pregapsize: 255
Track 03: audio   46 MB (04:38.85) no preemp pad     
Track 04: audio   42 MB (04:11.92) no preemp pad     
Track 05: audio   40 MB (04:01.60) no preemp pad     
Track 06: audio   40 MB (04:03.14) no preemp pad     
Track 07: audio   52 MB (05:11.24) no preemp pad     
Track 08: audio   42 MB (04:13.93) no preemp pad     
Track 09: audio   60 MB (06:02.55) no preemp pad     
Track 10: audio   48 MB (04:46.58) no preemp pad     
Track 11: audio   54 MB (05:23.34) no preemp pad     
Track 12: audio   61 MB (06:07.83) no preemp pad     
Track 13: audio   40 MB (03:58.10) no preemp pad     
Track 14: audio   29 MB (02:57.86) no preemp pad     
Track 15: audio   23 MB (02:21.79) no preemp pad     
Track 16: audio   35 MB (03:33.86) no preemp pad     
Track 17: audio   32 MB (03:11.63) no preemp pad     
Track 18: audio   23 MB (02:20.48) no preemp pad     
Track 19: audio   27 MB (02:42.03) no preemp pad     
Track 20: audio   29 MB (02:53.19) no preemp pad     
Total size:      803 MB (79:38.24) = 358368 sectors
Lout start:      804 MB (79:40/18) = 358368 sectors

and the disk burns and functions properly. Maybe I don't understand the problem fully . Anyway , I want to find how to calculate the ending disk size according to cdRecord from the total raw data my front end calculates ( 791.513MB vs 804MB from cdRecords numbers ). Any ideas?

[SaGS]

Originally Posted by jpollard

790 MB is a bit more than what should be on a CD (650–870MB depending on the exact CDR and the media). Normal limits are 650MB (should always fit) as data expands a bit when recorded to CD.

That’s true for data CDs, which hold 2048 actual data bytes + extra bytes for error correction in each sector.

IIRC audio CDs hold 2352 bytes/sector for the audio data, so the ISO image is larger than that of a data CD. For a 74 min CD (‘650 MB’) we have 74 min × 60 sec × 75 sectors × 2352 bytes = approx 747 MB of audio, for a 80 min CD (‘703 MB’) we have 807 MB of audio, and 908 MB for a 90 min (89min59sec74frames) disk.

[jpollard]

Same sector data, but uses a different format with less error recovery. Data sectors contain error recovery that Audio doesn't have.

Audio CDs are the same as data CDs other than that. I've made a few before. And if you exceed what will fit it doesn't work - and how large the result depends on the sampling rate. Which is why using cdrecord to report what will fit is the way to go.

[george_toolan]

You're comparing apples and oranges.

Track 01: data 42 MB

A 42 MiB data track will use more space on the disc than a 42 MiB audio track, because audio tracks have less error correction.

You could try to convert that into seconds. A data track will use exactly 150 KiB/sec (standard x1 cd speed).

42*1024/150 = 287 seconds

Now you can add those seconds to your audio seconds ;-)