Wen Bin discovered that bchunk, an application that converts a CD image in bin/cue format into a set of iso and cdr/wav tracks files, did not properly check its input. This would allow malicious users to crash the application or potentially execute arbitrary code.
CVE: (none) => CVE-2017-15955
Assigning to all packagers collectively, since there is no registered maintainer for this package.
CC: (none) => geiger.david68210, marja11Whiteboard: (none) => MGA6TOO, MGA5TOOVersion: 6 => CauldronAssignee: bugsquad => pkg-bugs
Debian has issued an advisory for this on November 9: https://www.debian.org/security/2017/dsa-4026
Source RPM: bchunk => bchunk-1.2.0-15.mga7.src.rpmSummary: bchunk security update CVE-2017-15953, CVE-2017-15954, CVE-2017-15955. => bchunk new security issues CVE-2017-15953, CVE-2017-15954, CVE-2017-15955CVE: CVE-2017-15955 => CVE-2017-1595[3-5]
Suggested advisory: ======================== The updated package fixes security vulnerabilities: bchunk (related to BinChunker) 1.2.0 and 1.2.1 is vulnerable to a heap-based buffer overflow and crash when processing a malformed CUE (.cue) file. (CVE-2017-15953) bchunk (related to BinChunker) 1.2.0 and 1.2.1 is vulnerable to a heap-based buffer overflow (with a resultant invalid free) and crash when processing a malformed CUE (.cue) file. (CVE-2017-15954) bchunk (related to BinChunker) 1.2.0 and 1.2.1 is vulnerable to an "Access violation near NULL on destination operand" and crash when processing a malformed CUE (.cue) file. (CVE-2017-15955) References: https://www.debian.org/security/2017/dsa-4026 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15953 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15954 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15955 ======================== Updated package in 5/core/updates_testing: ======================== bchunk-1.2.0-13.1.mga5 from SRPMS: bchunk-1.2.0-13.1.mga5.src.rpm Updated package in 6/core/updates_testing: ======================== bchunk-1.2.0-14.1.mga6 from SRPMS: bchunk-1.2.0-14.1.mga6.src.rpm
Assignee: pkg-bugs => qa-bugsSource RPM: bchunk-1.2.0-15.mga7.src.rpm => bchunk-1.2.0-14.mga6.src.rpmStatus: NEW => ASSIGNEDCC: (none) => nicolas.salgueroWhiteboard: MGA6TOO, MGA5TOO => MGA5TOOVersion: Cauldron => 6
Mageia 6 ob x86_64 Having a look at this. As a first step tried copying a CD to disk as a bin/cue pair but the process fell asleep halfway through. Shall start again with another CD.
CC: (none) => tarazed25
Mageia 5 for x86_64 First step: Convert a CD to bin/cue format. Load a CD and generate the bin and cue files on disk using cdrdao. It takes a while. https://tuxicity.wordpress.com/2007/02/26/cdrdao-copy-your-cd-and-burn-bin-cue-or-toc-files-on-the-cli/ $ cdrdao read-cd TheCars.cue Cdrdao version 1.2.3 - (C) Andreas Mueller <andreas@daneb.de> /dev/sr0: ATAPI iHAS124 E Rev: 4L07 Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0000) Reading toc and track data... Track Mode Flags Start Length ------------------------------------------------------------ 1 AUDIO 0 00:00:00( 0) 03:45:15( 16890) 2 AUDIO 0 03:45:15( 16890) 03:30:12( 15762) ............................. PQ sub-channel reading (audio track) is supported, data format is BCD. Raw P-W sub-channel reading (audio track) is supported. Cooked R-W sub-channel reading (audio track) is supported. Copying audio tracks 1-13: start 00:00:00, length 50:16:32 to "data.bin"... Track 1... Track 2... Found pre-gap: 00:00:16 Track 3... ............................. Track 13... Found pre-gap: 00:00:04 Found 639 Q sub-channels with CRC errors. Found disk catalogue number. Reading of toc and track data finished successfully. $ ls -l -rw-r--r-- 1 lcl lcl 532097664 Nov 20 20:48 data.bin -rw-r--r-- 1 lcl lcl 1521 Nov 20 20:48 TheCars.cue The cue file is a track index for the data file. Some information on bchunk at http://he.fi/bchunk/ and detailed usage information in the man pages. $ bchunk -w data.bin TheCars.cue TheCars binchunker for Unix, version 1.2.0 by Heikki Hannikainen <hessu@hes.iki.fi> Created with the kind help of Bob Marietta <marietrg@SLU.EDU>, partly based on his Pascal (Delphi) implementation. Support for MODE2/2352 ISO tracks thanks to input from Godmar Back <gback@cs.utah.edu>, Colas Nahaboo <Colas@Nahaboo.com> and Matthew Green <mrg@eterna.com.au>. Released under the GNU GPL, version 2 or later (at your option). Reading the CUE file: ... ouch, no space after track number. Track $ No idea what that means. Editing the cue file by adding a space after the track numbers does no good so the error must refer to something else. Nope. Reading the code on github shows that the input strings are parsed and linefeeds converted to binary zeroes (nulls). The word Track is printed if "TRACK" is encountered in the cue file and if the next character is not a space an error is reported. The program gets past that and looks for a space after the track number, which it should find because I had just added it. Looks like an obscure and unreported bug. See https://github.com/phracker/bchunk/blob/master/bchunk.c, lines 421... Nope again. The program "should" be looking for "Track" in the preceding comment. "TRACK" is always followed by " AUDIO\n" so that is why this fails. This data was generated by cdrdao. There is no way the bug should be attributed to cdrdao. bchunk should be doing a case insensitive search on '// Track' IMHO. My feeling is that a bug should be raised on this. Meanwhile this test got slightly further by a global edit of the cue file. Reading the CUE file: Track 1: (?) ... ouch, no space after track number. There are in fact spaces after the numbers. Removing them produced this: Reading the CUE file: ... ouch, no space after track number. Track $ This is not making any sense. Going to update and see if anything changes.
Figured it out. cdrdao is at fault. It generates the wrong format for the cue file. It places the track numbers in the comments instead of inline with the data. Nothing wrong with bchunk and after presenting an edited version of the cue file it ran OK. Reading the CUE file: Track 1: AUDIO Track 2: AUDIO Track 3: AUDIO Track 4: AUDIO Track 5: AUDIO Track 6: AUDIO Track 7: AUDIO Track 8: AUDIO Track 9: AUDIO Track 10: AUDIO Track 11: AUDIO Track 12: AUDIO Track 13: AUDIO Writing tracks: 1: TheCars01.cdr mmc sectors -1->-1 (1) mmc bytes 0->0 (1) sector data at 0, 2352 bytes per sector real data 2352 bytes 0/0 MB [********************] 100 % ................................ 13: TheCars13.cdr mmc sectors -1->226232 (226234) mmc bytes 0->532097664 (532097665) sector data at 0, 2352 bytes per sector real data 532102368 bytes 507/507 MB [********************] 100 % $ file *.cdr TheCars01.cdr: data TheCars02.cdr: data TheCars03.cdr: data TheCars04.cdr: data TheCars05.cdr: data TheCars06.cdr: data TheCars07.cdr: data TheCars08.cdr: data TheCars09.cdr: data TheCars10.cdr: data TheCars11.cdr: data TheCars12.cdr: data TheCars13.cdr: data Deleting these and updating now.
One thing to note here is that most of the data resides in the last file of the series. in this case TheCars13.cdr. $ ls -l *.cdr -rw-r--r-- 1 lcl lcl 2352 Nov 20 23:14 TheCars01.cdr -rw-r--r-- 1 lcl lcl 2352 Nov 20 23:14 TheCars02.cdr -rw-r--r-- 1 lcl lcl 2352 Nov 20 23:14 TheCars03.cdr -rw-r--r-- 1 lcl lcl 2352 Nov 20 23:14 TheCars04.cdr -rw-r--r-- 1 lcl lcl 2352 Nov 20 23:14 TheCars05.cdr -rw-r--r-- 1 lcl lcl 2352 Nov 20 23:14 TheCars06.cdr -rw-r--r-- 1 lcl lcl 2352 Nov 20 23:14 TheCars07.cdr -rw-r--r-- 1 lcl lcl 2352 Nov 20 23:14 TheCars08.cdr -rw-r--r-- 1 lcl lcl 2352 Nov 20 23:14 TheCars09.cdr -rw-r--r-- 1 lcl lcl 2352 Nov 20 23:14 TheCars10.cdr -rw-r--r-- 1 lcl lcl 2352 Nov 20 23:14 TheCars11.cdr -rw-r--r-- 1 lcl lcl 2352 Nov 20 23:14 TheCars12.cdr -rw-r--r-- 1 lcl lcl 532097664 Nov 20 23:14 TheCars13.cdr and the same is true for the generated WAVE files after: $ bchunk -ws data.bin TheCars.cue TheCars. ...... -rw-r--r-- 1 lcl lcl 2396 Nov 20 23:20 TheCars12.wav -rw-r--r-- 1 lcl lcl 532097708 Nov 20 23:20 TheCars13.wav -s was used to swap the bytes in the audio stream.
Back to Mageia 6::x86_64 Tried the POC from https://github.com/extramaster/bchunk/issues/3 before the update. Replaced the TheCars.cue file by the POC file and ran it against the existing data.bin file. Not sure if that was a valid way to test it but did not expect it to do anything useful anyway because it is full of malformed data. $ bchunk -ws data.bin poc19.cue TheCars ...................... Track 1: MODE1/2352 Track 1: �YY (?) Track 1: TRACK (?) Track 1: MODE1/23520d (?) 01 00:003:02 Track 1: MODE1/2352 Track 1569325056: 01 00:00:0D1 (?) 01 00:003:02 01 00:00:0D1 1/2352 01 00 INDEX 01 00:003:02... ouch, no space after INDEX. Writing tracks: 1: TheCars01.iso 0/0 MB [********************] 100 % 1: TheCars01.ugh 0/0 MB [********************] 100 % 1: TheCars01.ugh 0/0 MB [********************] 100 % 1: TheCars01.ugh 0/0 MB [********************] -0 % 1: TheCars01.iso 0/0 MB [********************] 100 % 1569325056: TheCars1569325056.ugh 506/506 MB [********************] 100 % $ $ ls -l TheCars* -rw-r--r-- 1 lcl lcl 468992 Nov 21 10:07 TheCars01.iso -rw-r--r-- 1 lcl lcl 0 Nov 21 10:07 TheCars01.ugh -rw-r--r-- 1 lcl lcl 531563760 Nov 21 10:08 TheCars1569325056.ugh I could not understand why the earlier test of bchunk produced a dozen small files and one large one. The smaller files were not playable as WAVE files. Found a description of the bin/cue syntax for the cue file online and used that as the basis for editing the existing cue file (produced by running cdrdao against a mounted CD-ROM). The cue file now looks like this: CD_DA CATALOG "9604640200007" FILE "data.bin" BINARY TRACK 1 AUDIO NO PRE_EMPHASIS TWO_CHANNEL_AUDIO INDEX 01 0 03:44:74 ......... several similar sections ........... TRACK 13 AUDIO NO PRE_EMPHASIS TWO_CHANNEL_AUDIO INDEX 13 46:43:23 03:33:09 START 00:00:04 $ bchunk -ws data.bin Cars.cue TheCars binchunker for Unix, version 1.2.0 by Heikki Hannikainen <hessu@hes.iki.fi> ................................. Reading the CUE file: Track 1: AUDIO 01 0 03:44:74 Track 2: AUDIO 02 03:44:74 03:30:23 .................................. Track 12: AUDIO 12 42:46:39 03:56:59 Track 13: AUDIO 13 46:43:23 03:33:09 Writing tracks: 1: TheCars01.wav 30/30 MB [********************] 100 % 2: TheCars02.wav 35/35 MB [********************] 100 % .......................................... 12: TheCars12.wav 39/39 MB [********************] 100 % 13: TheCars13.wav 35/35 MB [********************] 100 % The individual .wav files can be played.
Running the POC file after the update produces a different result. $ bchunk -ws data.bin poc19.cue TheCars binchunker for Unix, version 1.2.0 by Heikki Hannikainen <hessu@hes.iki.fi> ...................................................... Reading the CUE file: Track 1: MODE1/2352 Track 1: �YY (?) Track 1: TRACK (?) Track 1: MODE1/23520d (?) 01 00:003:02 Track 1: MODE1/2352 Track 1569325056: 01 00:00:0D1 (?) 01 00:003:02 01 00:00:0D1 1/2352 01 00 INDEX 01 00:003:02... ouch, no space after INDEX. At least there is no attempt this time to write any tracks so it looks as if the patches have improved things but it is not obvious how the POC addresses the issues. I think it is meant to cover CVE-2017-15953 and 15954. Tried bchunk again to create separate tracks for writing to a CD but have no real idea about what modes to use in the cue file. Raw mode was specified on the command line but all output came out as iso files. $ bchunk -r data.bin TheCars_cdr.cue TheCars Reading the CUE file: Track 1: MODE2/2352 01 0 03:44:74 Track 2: MODE2/2352 02 03:44:74 03:30:23 ................................ Writing tracks: 1: TheCars01.iso 30/30 MB [********************] 100 % 2: TheCars02.iso 35/35 MB [********************] 100 % cdrecord defaults to wodim. Tried: $ wodim dev=/dev/sr0 TheCars*.iso wodim: No write mode specified. wodim: Assuming -tao mode. wodim: Future versions of wodim may have different drive dependent defaults. wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits. Device type : Removable CD-ROM Version : 5 Response Format: 2 Capabilities : Vendor_info : 'HL-DT-ST' Identification : 'DVDRWBD CA30N ' Revision : 'A200' Device seems to be: Generic mmc2 DVD-R/DVD-RW. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R Speed set to 4234 KB/s Starting to write CD/DVD at speed 24.0 in real TAO mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. WARNING: padding up to secsize. Track 01: Total bytes read/written: 31754352/31756288 (15506 sectors). and so on. The final CD could be opened in vlc but nothing recognizable could be heard. The playlist registered 13 tracks and tracks could be skipped but there was no sound except sudden bursts of static every now and again. Typical vlc output: [00007f7920003428] cdda demux error: cannot read sector 264 [00007f7920003428] cdda demux error: could not read block 15923 from disc [00007f79240065b8] core input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 8506 ms ignored) [00007f7920003428] cdda demux error: could not read block 33926 from disc [00007f7920005898] cdda demux error: could not read block 50058 from disc [00007f7920005898] cdda demux error: cannot read sector 0 If the -s parameter is given to bchunk the audio bytes are swapped and the resulting CD produces a continuous stream of static. Note, from the diagnostics, that the SWABAUDIO driver is being used. So, two coasters so far. These problems are almost certainly due to my lack of competence in the audio field. There may well be combinations of parameters in the cue file and for the bchunk and wodim commands which could solve this. bchunk is what we are testing but the toolchain within which it is being tested requires more expert knowledge.
MGA5-64 on Lenovo B50 KDE No installation issues. I don't get it, at CLI: $ cdrdao read-cd kerst.cue Cdrdao version 1.2.3 - (C) Andreas Mueller <andreas@daneb.de> /dev/sr0: PLDS DVD-RW DA8A6SH Rev: GL61 Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0000) Reading toc and track data... Track Mode Flags Start Length ------------------------------------------------------------ 1 AUDIO 2 00:00:00( 0) 02:35:45( 11670) 2 AUDIO 2 02:35:45( 11670) 03:19:00( 14925) and more till 11 AUDIO 2 34:40:13(156013) 03:11:16( 14341) Leadout AUDIO 2 37:51:29(170354) PQ sub-channel reading (audio track) is supported, data format is BCD. Copying audio tracks 1-11: start 00:00:00, length 37:51:29 to "data.bin"... Track 1... Found ISRC code. Found 116188 Q sub-channels with CRC errors. Reading of toc and track data finished successfully. then the cue file starts (after removing the "//" before the track number): CD_DA Track 1 TRACK AUDIO COPY NO PRE_EMPHASIS TWO_CHANNEL_AUDIO ISRC "H00000000000" FILE "data.bin" 0 02:35:45 Track 2 TRACK AUDIO COPY NO PRE_EMPHASIS TWO_CHANNEL_AUDIO FILE "data.bin" 02:35:45 03:19:00 Track 3 and so on..... then$ bchunk -w data.bin kerst.cue kerst binchunker for Unix, version 1.2.0 by Heikki Hannikainen <hessu@hes.iki.fi> Created with the kind help of Bob Marietta <marietrg@SLU.EDU>, partly based on his Pascal (Delphi) implementation. Support for MODE2/2352 ISO tracks thanks to input from Godmar Back <gback@cs.utah.edu>, Colas Nahaboo <Colas@Nahaboo.com> and Matthew Green <mrg@eterna.com.au>. Released under the GNU GPL, version 2 or later (at your option). Reading the CUE file: ... ouch, no space after track number. Surely, there is 67 Gb free space, but my cue file is substantially different from what Len shows in Comment 8
CC: (none) => herman.viaene
Re comment 10: Herman these "... ouch, no space after track number" messages come from the parser section of bchunk, where it is reading the cue file. "space" here means the text character for space. Removing the comment characters would probably have little effect because the parser looks specifically for uppercase TRACK, probably because that is what is specified in the documentation (which might be OK in the Windows world but is definitely not in the UNIX world). That means that the track numbers are missed, I think. When I removed the comments the file read: Track 1 TRACK AUDIO and the error message was: ... ouch, no space after track number. Track $ The code is this: if ((p = strstr(s, "TRACK"))) { printf("\nTrack "); if (!(p = strchr(p, ' '))) { fprintf(stderr, "... ouch, no space after TRACK.\n"); continue; } p++; if (!(t = strchr(p, ' '))) { fprintf(stderr, "... ouch, no space after track number.\n"); continue; } So in my case 'Track 1' was passed over. Next line was 'TRACK AUDIO' so it printed 'Track ' on a new line. The next line of code looks for a space, which it should find. In the updated specification the next character(s) should be a decimal number followed by another space and properties like AUDIO or MODE. It would then continue to the next section to check that the next word terminates on a space. That should be the track number - at this time the pointer rests on the start of 'AUDIO' where bchunk expects to find the track number and looks for the space separator beyond it and hits the string terminator instead. Hence the "ouch". It was reasoning back from this point that led me to look for a specification for cue files. It seemed clear that the correct format would be "TRACK <number> <something>". And no, I am not suggesting that as QA testers we should be expected to do this sort of analysis, but in this case the links were readily available so it seemed worth following up. Maybe worth raising a bug against our version of cdrdao.
Re Comment 10; ouch, that was a joke, right?
The solution to writing the audio CD is to use our old friend k3b. Works perfectly0 on the WAVE files generated by bchunk earlier. The CD plays back just like the original. wodim is used internally to burn the tracks but k3b knows how to handle it. This is OK for 64 bits on Mageia 6.
Whiteboard: MGA5TOO => MGA5TOO MGA6-64-OK
Trying out : added space after the track number in the cue file, still "ouch..." Next add a space after each "TRACK AUDIO" so it reads "TRACK AUDIO " for each track. Now at CLI: $ bchunk -w data.bin kerst.cue kerst binchunker for Unix, version 1.2.0 by Heikki Hannikainen <hessu@hes.iki.fi> Created with the kind help of Bob Marietta <marietrg@SLU.EDU>, partly based on his Pascal (Delphi) implementation. Support for MODE2/2352 ISO tracks thanks to input from Godmar Back <gback@cs.utah.edu>, Colas Nahaboo <Colas@Nahaboo.com> and Matthew Green <mrg@eterna.com.au>. Released under the GNU GPL, version 2 or later (at your option). Reading the CUE file: Track 0: (?) Track 0: (?) Track 0: (?) Track 0: (?) Track 0: (?) Track 0: (?) Track 0: (?) Track 0: (?) Track 0: (?) Track 0: (?) Track 0: (?) Writing tracks: 0: kerst00.ugh 0/0 MB [********************] 100 % 0: kerst00.ugh 0/0 MB [********************] 100 % 0: kerst00.ugh 0/0 MB [********************] 100 % 0: kerst00.ugh 0/0 MB [********************] 100 % 0: kerst00.ugh 0/0 MB [********************] 100 % 0: kerst00.ugh 0/0 MB [********************] 100 % 0: kerst00.ugh 0/0 MB [********************] 100 % 0: kerst00.ugh 0/0 MB [********************] 100 % 0: kerst00.ugh 0/0 MB [********************] 100 % 0: kerst00.ugh 0/0 MB [********************] 100 % 0: kerst00.ugh 382/382 MB [********************] 100 % Reading on ugh file format, it claims to be an iso, just renaming should do. Took a copy and renamed that to kerst00.iso and tried to mount it with -t iso9660, but that fails. I find in dmesg ISOFS: Unable to identify CD-ROM format.
Re comment 14. You are treading the same path as I did. The simplest solution is to change the format of the cue file because as pointed out earlier the bchunk parser is expecting something like my cue file retread which was based on the article at https://en.wikipedia.org/wiki/Cue_sheet_(computing) which was last edited 2017-08-19. With a bit of global editing you should be able to transform your cue file fairly quickly.
Re Comment 15. Of course I follow you, you cleared the path. And from my posting you might conclude that I have a correct cue file now. The snag now is that I cannot use the output I get from bchunk anyway I know.
Tested this in virtualbox for Mageia 6 i586. bchunk updated OK. data.bin and the cue file created on the host using $ cdrdao read-cd Susato.cue which created data.bin and a malformed cue file. Modified the cue file in line with the recipe at https://en.wikipedia.org/wiki/Cue_sheet_(computing) to index all 29 tracks and then copied the renamed data.bin and cue files to the guest. Ran bchunk on the guest machine to generate WAVE files with swapped bytes. $ bchunk -ws AtTheSignOfTheCrumhorn.bin Susato.cue crumhorn That worked fine and any of the 29 crumhorn*.wav files could be played using sox (the play command). This is enough to show that bchunk is working properly for 32 bits.
Whiteboard: MGA5TOO MGA6-64-OK => MGA5TOO MGA6-64-OK MGA6-32-OK
Created attachment 9799 [details] Specimen cue file to use with bchunk. Our current cdrdao generates data.bin and a cue file in what appears to be an outdated configuration format which bchunk objects to. An example file which would be acceptable to bchunk is available on the link referenced in the comments. It is tedious to do but editing the bad cue file may be the best approach.
Keywords: (none) => advisory
Trying to see the wood from the trees; to set the scene for myself for trying this on Mageia 5. If you start with any old audio CD, I think these are the steps to try bchunk. 1. $ cdrdao read-cd <album>.cue [comment 5] Generates data.bin and <album>.cue files; but *the cue file is incorrect*. 2. Edit the cue file as per the example attachment for correct format. 3. $ bchunk -w data.bin <album>.cue <album> [comment 5] Produces *wav file per track I think; OR $ bchunk -ws data.bin <album>.cue <album> [comments 7 & 8] Accepting that 's' swaps bytes, produces *.wav files. [Comment 6] Produced *.cdr files per track; the bchunk command was not shown - without -w ? 4. The solution to writing the audio CD is to use our old friend k3b. Works perfectly on the WAVE files generated by bchunk earlier. [13] Which should play normally; back where we started? Just installed PRE-update: bchunk-1.2.0-13.mga5.x86_64 A bit the wiser: bchunk converts a CD image in a ".bin / .cue" format (sometimes ".raw /.cue") to a set of .iso and .cdr tracks. $ bchunk ...options... <image.bin> <image.cue> <basename> image.bin is the raw cd image file. image.cue is the track index file containing track types and offsets. basename is used for the beginning part of the created track files. *.cdr Audio tracks in native CD audio format. They can be either written on a CD-R using 'cdrecord -audio', or converted to WAV (or any other sound format for that matter) using sox ('sox track.cdr track.wav'). [I thought WAV/FLACC was the same as 'native CD audio format'] -w Makes binchunker write audio tracks in WAV format. Without this option, does one get .cdr format by default? -s Makes binchunker swap byte order in the samples of audio tracks. To explore.
CC: (none) => lewyssmith
Re comment 19: [I thought WAV/FLACC was the same as 'native CD audio format'] Yes; WAV is the raw format for CD disks as I understand it and FLAC is a lossless compression format used for storing audio. Audio players have to decompress that on the fly. Have just confirmed that the play command can handle that, so it is built in to sox.
Trying to iron out some confusion here; $ bchunk data.bin cuefile prefix produces .cdr tracks which can be played through sox. $ bchunk -ws data.bin cuefile prefix produces .wav files which play through sox. Omitting the byte-swap switch produces .wav files which play as a stream of noise. If the playable WAV files are written to disk via k3b wodim is invoked and that uses the SWABAUDIO driver to write the tracks, presumably in native CD format (cdr?). Comparing hexdumps of the two formats did not convince me that CDR and WAV formats are byte-swapped versions of each other as I originally thought. So, confusion reigns.
Testing M5/64 BEFORE the update: bchunk-1.2.0-13.mga5.x86_64 $ cdrdao read-cd test.cue Cdrdao version 1.2.3 - (C) Andreas Mueller <andreas@daneb.de> /dev/sr0: ATAPI DVD A DH16ACSH Rev: JA11 Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0000) Reading toc and track data... Track Mode Flags Start Length ------------------------------------------------------------ 1 AUDIO 0 00:00:32( 32) 02:48:33( 12633) ... 20 AUDIO 0 57:38:57(259407) 07:35:00( 34125) Leadout AUDIO 0 65:13:57(293532) PQ sub-channel reading (audio track) is supported, data format is BCD. Raw P-W sub-channel reading (audio track) is supported. Cooked R-W sub-channel reading (audio track) is supported. Copying audio tracks 1-20: start 00:00:00, length 65:13:57 to "data.bin"... Track 1... Track 2... Found pre-gap: 00:00:06 .............. Track 20... Found pre-gap: 00:00:22 Found 2853 Q sub-channels with CRC errors. Found disk catalogue number. Reading of toc and track data finished successfully. This produced 'data.bin' and 'test.cue' which I edited heavily taking Len's hints, being careful about consistency of the 3 fields re track number: TRACK, ISRC (does this matter?), INDEX. The edited test.cue starts: CD_DA CATALOG "0000007479472" FILE "data.bin" BINARY [I guessed this is what was required] TRACK 1 AUDIO NO PRE_EMPHASIS TWO_CHANNEL_AUDIO ISRC "HKI199836901" [I imagine this is arbitrary here] INDEX 01 0 02:48:59 START 00:00:32 et seq to the end: TRACK 20 AUDIO NO PRE_EMPHASIS TWO_CHANNEL_AUDIO ISRC "HKI199836920" INDEX 20 57:38:35 07:35:22 START 00:00:22 Just to probe what would happen: $ bchunk data.bin test.cue test ... Reading the CUE file: Track 1: AUDIO 01 0 02:48:59 Track 2: AUDIO 02 02:48:59 02:22:42 ... Track 20: AUDIO 20 57:38:35 07:35:22 Writing tracks: 1: test01.cdr 20/20 MB [********************] 100 % ... 20: test20.cdr 76/76 MB [********************] 100 % Yes, *.cdr files per track. Deleted them to try the updated package. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ AFTER update to: bchunk-1.2.0-13.1.mga5 Trying with no options to produce a .cdr file per track: $ bchunk data.bin test.cue test Output as previously. $ ls test??.cdr test01.cdr test05.cdr test09.cdr test13.cdr test17.cdr test02.cdr test06.cdr test10.cdr test14.cdr test18.cdr test03.cdr test07.cdr test11.cdr test15.cdr test19.cdr test04.cdr test08.cdr test12.cdr test16.cdr test20.cdr Tried listening to a few of the .cdr files with sox/play: $ play testxx.cdr They sounded fine. So this process works. Next try producing WAV files per track: $ bchunk -ws data.bin test.cue test [Thanks Len for the swap param] ... Reading the CUE file: Track 1: AUDIO 01 0 02:48:59 Track 2: AUDIO 02 02:48:59 02:22:42 ... Track 20: AUDIO 20 57:38:35 07:35:22 Writing tracks: 1: test01.wav 20/20 MB [********************] 100 % ... 20: test20.wav 76/76 MB [********************] 100 % $ ls test??.wav test01.wav test05.wav test09.wav test13.wav test17.wav test02.wav test06.wav test10.wav test14.wav test18.wav test03.wav test07.wav test11.wav test15.wav test19.wav test04.wav test08.wav test12.wav test16.wav test20.wav Played a selection of these with various programs: mpv, xine, Amarok, VLC, Audacity, Parole. All worked OK. This seems the end of bchunk's responsibility; I did not see the point of re-assembling the tracks to make an audio CD clone of the original. FWIW the .cdr and .wav files differed in size just within the final 1000 bytes. OK & validating - at last.
Keywords: (none) => validated_updateWhiteboard: MGA5TOO MGA6-64-OK MGA6-32-OK => MGA5TOO MGA6-64-OK MGA6-32-OK MGA5-64-OKCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2017-0426.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
A little research on the subject of audio encoding on CDs reveals that the situation is a lot more complex than implied in comment 20. WAV format does not correspond directly with the way audio is encoded on CDs, which is actually governed by Red Book audio.