In TOC files which do not have a LANGUAGE_MAP defined, cdrdao(1) says that data in LANGUAGE blocks should be ignored.
However, this rule is inconsistenly followed; global LANGUAGE contents are ingored, but track-specific LANGUAGE contents are not ingnored.
It would be wonderful if the global LANGUAGE contents could be decoded too (parsing forgivably, and making the data used), or if not, at least the track LANGAUAGEs perhaps should not be decoded either, which at least may indicate to the user that something is wrong.
(That said, in this case, as far as I remember, cdrdao was the culprit which produced the malformed TOC file, so cdrdao itself is breaking its own spec :-) )
In TOC files which do not have a
LANGUAGE_MAPdefined,cdrdao(1)says that data inLANGUAGEblocks should be ignored.However, this rule is inconsistenly followed; global
LANGUAGEcontents are ingored, but track-specificLANGUAGEcontents are not ingnored.It would be wonderful if the global
LANGUAGEcontents could be decoded too (parsing forgivably, and making the data used), or if not, at least the trackLANGAUAGEs perhaps should not be decoded either, which at least may indicate to the user that something is wrong.(That said, in this case, as far as I remember,
cdrdaowas the culprit which produced the malformed TOC file, socdrdaoitself is breaking its own spec :-) )